expose a TLS Keying Material Exporter / unique value for the TLS session

[marten-seemann]

It would be useful to expose a TLS Key Exporter (RFC 5707), or at least a value that's derived from the TLS master secret, and therefore unique to the TLS session.

This is a useful building block for protocols running on top of TLS:

1. The (somewhat misleadingly named) HTTP Transport Authentication draft uses a TLS Keying Material Exporter. Note that I'm not suggesting to implement exactly this draft, just something along these lines.
2. In the p2p setting, peers might run a secondary handshake on top of a WebTransport session. Having access to a value unique to the TLS session would allow one to bind the that handshake to the TLS session.

[jan-ivar]

Meeting:

• It might be helpful to have an example of what this would be useful for.
• Is there any API precedent for this in the web platform we could follow?
• What JS API surface do you have in mind?

[marten-seemann]

It might be helpful to have an example of what this would be useful for.

I already listed the HTTP Transport Authentication draft before. I'm happy to expand on my use case: In libp2p, a general-purpose p2p networking library, we're planning to use WebTransport to allow browsers to connect to the rest of the network. Specifically, we'll use the serverCertificateHashes API to be able to use self-signed certificates. We run a secondary handshake on one stream after to make sure the connection wasn't MITMed (as the address exchange, which includes the server's certificate hash, is not necessarily authenticated).

Is there any API precedent for this in the web platform we could follow?

Not that I'm aware of. However, in WebRTC the same can be achieved using the tuple of the certificate hashes from both SDPs.

What JS API surface do you have in mind?

I don't have a lot of experience designing browser APIs, but these two options would work:

• a callback similar to ExportKeyingMaterial in Go, implementing a key exporter according to RFC 5707
• or much simpler: a single value (byte array) derived from a key exporter

[jan-ivar]

@martinthomson any concerns with exposing keying material like this?

[martinthomson]

That's what exporters are for, so, not in that respect.

[pthatcher]

This seems like a reasonable API request to me, and would be fairly simple:

.exportKeyMaterial(label, context, len)

However, I worry about a label being reused. So, you go get key material and use it, but another tab (when using WebTransport pooling) uses the same label and learns your key material. Or some built-in browser thing in the future uses a label and then you learn key material by using the same label.

Perhaps we could fix this with a rule like "you can't reuse the same label more than once for the same WebTransport".

[martinthomson]

With pooling, we might need to add something extra (based on the session ID probably) to the exporter label or context so that different sessions get different keys.

I would also look to webcrypto for the API. It might be that we only need to export a single, fixed value, which can then be used as input to webcrypto functions.

[jan-ivar]

Meeting:

• some support for this. API seems safe.
• a preference for using a prefix for the label, so we don't accidentally overlap with a non-WebTransport exporter

[vasilvv]

Note: I've filed ietf-wg-webtrans/draft-ietf-webtrans-http3#116 to possibly describe the actual operation in the IETF spec.

[Neustradamus]

To follow.

[Neustradamus]

Any progress on it?

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

Little details, to know easily:

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

Thanks in advance.

[jan-ivar]

@vasilvv it appears https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/116#issuecomment-1767275566 was closed "due to lack of interest". What are next steps here?

[vasilvv]

It's either (1) we find developers who can provide an explanation of how they're going to use this feature, or (2) we close this issue for the same reason.

[wilaw]

Closing per https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/116#issuecomment-1767275566

[sukunrt]

Hi, apologies for the delay. I'm taking over the work @marten-seemann mentioned for libp2p. We'd like to have this feature. The requirement is the same as Marten has shared before.

In libp2p, we identify nodes by their peer ID which is hash(public key). Currently, we use WebTransport with the serverCertificateHashes API. The client obtains the peer's peer ID and its WebTransport address (including the certificate hash). After establishing the WebTransport session, we run a Noise handshake on a WebTransport stream, which verifies that the peer does actually have the private key corresponding to its peer ID. In order to make sure the connection wasn't MITM-ed, the WebTransport certificate hash is hashed into the Noise handshake, which cryptographically ties the Noise handshake to the underlying WebTransport session.

We would like to extend our use of WebTransport to use the web PKI. Here, being able to derive a unique value would allow us to bind the TLS session to the Noise handshake, similar to how we use cert hashes above.

[hlandau]

I would also definitely like to see this. There's some use cases I've wanted to be able to do on the web platform for some time, but the lack of this functionality still holds things back.

[jan-ivar]

Meeting:

• General agreement this can be useful, and people asking for it.
• @vasilvv to reopen IETF issue

[wilaw]

See this PR https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/pull/148 from Victor

[wilaw]

https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/pull/148 was merged. How should W3C API surface change?

[jan-ivar]

Meeting:

• Next step is to propose an API surface for https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/pull/148 and RFC 5705.
• "unique to the TLS session."

[jan-ivar]

Meeting:

• probably a synchronous read only attribute.
• a byte array
• wt.exportedKey or a exportKey() method?

[vasilvv]

I don't think we can make this an attribute given that generating an exporter needs three arguments.

I'd also prefer making this async, since it makes it much easier to implement (it's possible to implement this synchronously, but it requires some cooperation from the TLS library, and has some unfortunate security implications).

[jan-ivar]

Meeting:

• the label (string with limitation), the context, and a third thing (check IETF specs). See https://ietf-wg-webtrans.github.io/draft-ietf-webtrans-http3/draft-ietf-webtrans-http3.html#section-4.7
• application needs to provide these
• http2 here only works with certain extensions enabled.
• probably a method then

[wilaw]

Note comments in https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/170#issue-2465995393

I would strongly suggest not to expose TLS exporters in client API as it will lead to inconsistent user experience depending on presence of a TLS proxy. These issues will be quite hard to troubleshoot for application developers as TLS proxies are typically deployed on client side.

[vasilvv]

Three things to note here before I forget:

1. That's part of the intended effect.
2. We already ship features that require direct connection (serverCertificateHashes)
3. At least in Chrome, we don't allow WebTransport when a proxy is configured for the URL in question, and I'm not sure at what point we'd support it. There are a lot of unclear implications when it comes to forward proxies, since WebTransport is an intentionally low-level networking API.

[jan-ivar]

Discussed at TPAC:

• Conclusion: implement asynchronous API as shown,

  const km = await wt.exportKeyMaterial(label, context)

[jan-ivar]

Meeting:

• If you have two tabs sharing the same TLS key, nothing prevents me from deriving an exporter that is the same as a nother tab would do. Typically this is prevented with hashing in a session id
• The other end is the same, so maybe not a huge problem?
• This is same-site only

[jan-ivar]

Covered by SESSION ID in https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/116