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-exporter for TLS = 1.3

Thanks in advance.

[mit-mit]

cc @brianquinlan

[a-siva]

//cc @brianquinlan

[brianquinlan]

@Neustradamus It wasn't clear from the BoringSSL bug (openssl/openssl#18893) that you filed whether the necessary BoringSSL features are in place - are they?

[Neustradamus]

@brianquinlan: About BoringSSL, it is not complete, you can compare:
1/ tls-unique:

• https://github.com/google/boringssl/search?q=tls-unique
• https://github.com/google/boringssl/search?q=rfc5929

2/ tls-exporter:

• https://github.com/google/boringssl/search?q=tls-exporter
• https://github.com/google/boringssl/search?q=rfc9266

From @agl, @davidben: tls-unique:

• google/boringssl@af0e32c
• google/boringssl@ced00b4

I have commented here:

• google/boringssl@ced00b4#commitcomment-79557686

I have requested more details:

Can you add more details like for previous "RFC5929":
- https://github.com/google/boringssl/search?q=rfc5929
- https://github.com/google/boringssl/search?q=tls-unique

Because we find nothing about: "RFC9266":
- https://github.com/google/boringssl/search?q=rfc9266
- https://github.com/google/boringssl/search?q=tls-exporter

[davidben]

@Neustradamus, as I explained in the other places you've been CCing us, no new APIs are needed to implement RFC 9266, in any of OpenSSL or its derivatives. Or, indeed, in most TLS libraries I expect. You simply call the existing APIs for TLS's "export keying material" mechanism. Any API specific to RFC 9266 would just be convenience wrappers over that underlying primitive.

I don't see a particular need to add a convenience wrapper to BoringSSL right now.

[Neustradamus]

@PapaTutuWawa: I have done ticket here, do not hesitated to explain your problem.

Linked to:

• RFC 9266: Channel Bindings for TLS 1.3 support PapaTutuWawa/moxxy#13

[PapaTutuWawa]

The issue comes from the fact that I would like to use TLS Channel Binding in my application using Dart to implement SCRAM-*-PLUS. For that, however, I would need access to the TLS connection's state (if that is the correct name) to get the neccessary data. Taking this Go SCRAM implementation as inspiration, something like Go's ExportKeyingMaterial would be required. As far as I know, Dart does not expose this kind of access in the SecureSocket class.

[Neustradamus]

Happy New Year 2023 to all!

Have you looked for this ticket and the @PapaTutuWawa comment?