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:

• [proposal] expose TLS Finished sent by the server in server and client hooks #442
• add getFinished and getPeerFinished functions for Context, closes #442 #445
• State of Play scram-sasl/info#1

[kazu-yamamoto]

I will probably spend time to improve tls for the next two months.
First I need to understand this RFC.

[Neustradamus]

@kazu-yamamoto: Good :)

Please read the RFC5929 before:

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

It is important to support previous TLS versions and TLS 1.3.

For example, XMPP needs some XEPs in more the main RFC6120 with SCRAM-SHA-*-PLUS variants:

• https://tools.ietf.org/html/rfc6120
• XEP-0388: Extensible SASL Profile: https://xmpp.org/extensions/xep-0388.html
• XEP-0440: SASL Channel-Binding Type Capability: https://xmpp.org/extensions/xep-0440.html
• XEP-0474: SASL SCRAM Downgrade Protection: https://xmpp.org/extensions/xep-0474.html
• XEP-0480: SASL Upgrade Tasks: https://xmpp.org/extensions/xep-0480.html

All SCRAM RFCs, I-Ds:

• State of Play scram-sasl/info#1

[kazu-yamamoto]

@Neustradamus Is it enough to revert 9b23d2a?
Or should I provide a wrapper function to specify "EXPORTER-Channel-Binding", "" and 32 to it?

[Neustradamus]

@kazu-yamamoto: I am not sure about it, I am not an Haskell dev...

But there are 3 parts which must be possible:

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

Haskell devs from 2 XMPP projects:

• https://github.com/pontarius/pontarius-xmpp: @jonkri, @Philonous, @l29ah, @singpolyma, @snoyberg, @rnons, @astro, @hiratara, @nh2, @dequbed, @MarcosPividori, @Kritzefitz
• https://github.com/SupercedeTech/haskell-xmpp: @jappeace, @johnz-at-riskbook, @NikitaRzm, @ivb-supercede, @NikitaRazmakhnin, @jezen, @vrom911

[kazu-yamamoto]

@epoberezkin I guess that you have an opinion on this.

[jappeace]

afaik supercede dropped xmpp and that package is depracated.

[kazu-yamamoto]

8795ab6 implements getTLSExporter and add a document to `getFinished'.
Let's close this.

[Neustradamus]

@kazu-yamamoto: Good job!

Now it supports 3 parts?

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

[kazu-yamamoto]

getFinished for (1) and getTLSExporter for (3) but no (2).
Should I implement (2), too?

[Neustradamus]

Yes for tls-server-end-point, it is needed, it is in:

• XEP-0388: Extensible SASL Profile: https://xmpp.org/extensions/xep-0388.html
• XEP-0440: SASL Channel-Binding Type Capability: https://xmpp.org/extensions/xep-0440.html
• XEP-0474: SASL SCRAM Downgrade Protection: https://xmpp.org/extensions/xep-0474.html
• XEP-0480: SASL Upgrade Tasks: https://xmpp.org/extensions/xep-0480.html

And it is in SASL2 I-D: Extensible Simple Authentication and Security Layer (SASL): https://datatracker.ietf.org/doc/html/draft-melnikov-sasl2

[kazu-yamamoto]

@epoberezkin I have implemented getTLSUnique which automatically selects the first Finished (see 1428994).
getFinished and getPeerFinished are deprecated in tls v2.0

[Neustradamus]

@kazu-yamamoto: Thanks!

You will remove the support of TLS 1.2 in 2.0?

Important: "tls-server-end-point" is needed too: it is in several XEPs and it will be in next SASL2 IETF RFC, an RFC which will replace: https://datatracker.ietf.org/doc/html/rfc4422.

You can look in all links cited in my previous comment.

[kazu-yamamoto]

The last comment was to @epoberezkin which implemented getFinished.
I'm now thinking how to implement "tls-server-end-point".

tls v2.0 supports both TLS 1.2 and TLS 1.3.

[Neustradamus]

@kazu-yamamoto: Ah sorry, too quick to read :)

Can you add comments in the code about "tls-unique" and RFC5929, "tls-server-end-point" and RFC5929, "tls-exporter" and RFC9266?
It is easy to look in the code.

Example in GnuTLS code:

• https://github.com/search?q=repo%3Agnutls%2Fgnutls+tls-unique&type=code
• https://github.com/search?q=repo%3Agnutls%2Fgnutls+tls-server-end-point&type=code
• https://github.com/search?q=repo%3Agnutls%2Fgnutls+tls-exporter&type=code
• https://github.com/search?q=repo%3Agnutls%2Fgnutls+rfc5929&type=code
• https://github.com/search?q=repo%3Agnutls%2Fgnutls+rfc9266&type=code

[kazu-yamamoto]

The old default for Extended Master Secret of TLS 1.2 was allowed.
But I changed it to required in 4cabdf3 to prevent triple handshake attack to "tls-unique".

[kazu-yamamoto]

@Neustradamus About comments. The binding name were already there. I added RFC stuff in their comments.

[Neustradamus]

Thanks @kazu-yamamoto!
All of this will not be added in a build before 2.0?

[kazu-yamamoto]

No.
Haskell tls does not have long term support versions like other Haskell libraries.
The Haskell community has a culture where libraries are very small and updated frequently.

[kazu-yamamoto]

I have implemented getTLSServerEndPoint. Both for TLS 1.2 and TLS 1.3, a channel binding is created with a certificate chain with the used hash.

[kazu-yamamoto]

What I'm not convinced yet:

• Does the calculation of "tls-unique" exclude HandshakeType and the length of the Handshake struct?
• Does the calculation of "tls-server-end-point" exclude HandshakeType and the length of the Handshake struct?
• How to apply "tls-server-end-point" for TLS 1.3?

[Neustradamus]

@kazu-yamamoto: I have sent you an email

[kazu-yamamoto]

@Neustradamus Yes. I have read the mail. Thank you.
But I don't think the email answers to my questions above.

I tried to read the code of OpenSSL but I don't understand SSL_get_finished yet.

[kazu-yamamoto]

@epoberezkin Would you tell me whether or not getFinished is inter-operable with OpenSSL?

[epoberezkin]

@kazu-yamamoto sorry for slow replies!

tlsunique should be available for TLS 1.3 too - we use exactly that now. While it was defined for TLS 1.2 it can be used with some caveats for TLS 1.3 too - it's just a digest over client's handshake.

@epoberezkin I have implemented getTLSUnique which automatically selects the first Finished (see 1428994).
getFinished and getPeerFinished are deprecated in tls v2.0

You really need both to get tlsunique binding in both client and server, I believe they should not be deprecated, because which one to use depends on client/server role and in any case they can be useful for debugging.

I am not sure what "the first Finished" means, if you want to have tlsunique available to both sides via a single then it should be getPeerFinished in the server and getFinished in the client.

Also, I believe tlsunique should not be used when session resumption is allowed (that was the motivation to offer new bindings for TLS 1.3 spec) - just looked briefly at this commit, so maybe you can make the new function throw exception unless resumption is disabled.

Does the calculation of "tls-unique" exclude HandshakeType and the length of the Handshake struct?

tlsunique is client's Finished value, as it's defined in TLS handshake, it should not be calculated differently

@epoberezkin Would you tell me whether or not getFinished is inter-operable with OpenSSL?

Good question. We did not test that.

[kazu-yamamoto]

@epoberezkin

(1) tls-server-end-point

The problem is that the structure of TLS 1.3 certificate is different from that of TLS 1.2:

TLS 1.2:

struct {
    ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;

TLS 1.3:

struct {
   opaque certificate_request_context<0..2^8-1>;
   Extension extensions<2..2^16-1>;
} CertificateRequest;

Some guys say "just use the entire of TLS 1.3 certificate" while others say "encode it into TLS 1.2 certificate".

(2) tls-unique

See the following figure to understand which is the first and which is the second.

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished(1)                  -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished(2)
      Application Data             <------->     Application Data

getTLSUnique returns the first Finished regardless of its role.
getFinished and getPeerFinished are error-prone because users must take care of its role.

The TLS message is composed as follows:

TLS record header
Handshake message header
Finished (verify_data)

RFC 5929 says:

note: the Finished struct, not the TLS record layer message containing it

If the handshake message header is not included, the spec should say so explicitly.

Anyway, the current specifications look ambiguous to me.
So, inter-operability test is important.