RFC 9266: Channel Bindings for TLS 1.3 support

[Neustradamus]

Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?

• https://datatracker.ietf.org/doc/html/rfc9266

Little details, to know easily:

• tls-unique for TLS =< 1.2
• tls-server-end-point
• tls-exporter for TLS = 1.3

I think that you have seen the jabber.ru MITM and Channel Binding is the solution:

• https://notes.valdikss.org.ru/jabber.ru-mitm/
• https://snikket.org/blog/on-the-jabber-ru-mitm/
• https://www.devever.net/~hl/xmpp-incident
• https://blog.jmp.chat/b/certwatch

Thanks in advance.

Linked to:

• Support exporter secrets, as defined in RFC 5705 & 8446 #482
• State of Play scram-sasl/info#1

[hannesm]

Sure, do you have an actual OCaml library or packet that would benefit from this directly? I don't like to work on something that is there just for implementing some RFC, but has no actual users.

As I understand it, for TLS 1.3 this is a no-opt (since #482 was merged) -- for TLS <= 1.2 there is still something to do (the tls-unique stuff).

[Neustradamus]

@hannesm: You have the choice to have the support of all possibilies like other softwares do:

• tls-unique for TLS =< 1.2
• tls-server-end-point
• tls-exporter for TLS = 1.3

There is this project but @alexeyshch has stopped the devel of new features but it is up-to-date:

• https://github.com/processone/jamler

Some OCaml projects:

• https://github.com/hannesm/jackline (you know the author ah ah)
• https://codeberg.org/openEngiadina/ocaml-xmppl
• https://codeberg.org/openEngiadina/geopub
• https://ox.tuxfamily.org/
• https://www.freshports.org/net/ocaml-jabbr/
• https://www.ejabberd.im/sulci/

[Neustradamus]

@hannesm: Have you looked to add missing 2 parts?

• tls-unique for TLS =< 1.2
• tls-server-end-point

[hannesm]

Dear @Neustradamus, thanks again for opening the issue.

I finally worked on the implenentation -- it is in #496. Do you have at hand either test vectors or some easy-to-test mechanism with the different channel binding types?

The API for a user is (please let me know if you consider this to be suitable)

(** [channel_binding epoch_data mode] is the RFC 5929 and RFC 9266 specified channel binding.
    Please note that [`Tls_unique] will error for TLS 1.3 sessions, and [`Tls_exporter] is not
    recommended for TLS < 1.3 sessions (unless the uniqueness is ensured via another path). *)
val channel_binding : Core.epoch_data -> [ `Tls_exporter | `Tls_unique | `Tls_server_endpoint ]
   -> (Cstruct.t, [ `Msg of string ]) result

[Neustradamus]

@hannesm: Nice, good job!

Have you looked for jackline? :)

@ermine, @pukkamustard, @Jehan, @alexeyshch: What do you think?

It must work with:

• ProcessOne ejabberd (XMPP server): https://www.ejabberd.im/
• Tigase XMPP (XMPP server): https://tigase.org/
• Jackal (XMPP server): https://github.com/ortuman/jackal
• Prosody IM (XMPP server): https://prosody.im/
• Metronome IM (XMPP server): https://metronome.im/
• DJabberd (XMPP server): https://github.com/djabberd/DJabberd

[hannesm]

Thanks for your references. Unfortunately all the xmpp servers I have accounts on don't provide the XEP 440 capability https://xmpp.org/extensions/xep-0440.html -- I also ran short on implementing scram.

But since I need to cut a release for another bugfix, I merged the channel binding PR to avoid having many open PRs.

[Neustradamus]

@hannesm: I think that you can test with https://movim.eu/ :)