Keying material exporters

[vasilvv]

Per w3c/webtransport#411, there is some interest in using key exporters with WebTransport. While in theory that could be purely an API concept, given that we do things like pooling (and given that we should register exporter labels with IANA), it probably would make sense to define the exact mechanism in this document.

I propose the following. A WebTransport exporter takes (label, context, length) as input, similar to the TLS ones. To derive a WebTransport exporter, derive a TLS key exporter with label EXPORTER-WebTransport and the context being the following:

WebTransport Exporter Context {
  WebTransport Session ID (64),
  WebTransport Application-Supplied Exporter Label Length (32),
  WebTransport Application-Supplied Exporter Label (..),
  WebTransport Application-Supplied Exporter Context (..)
}

This should help avoiding collisions with non-WebTransport exporters, as well as WebTransport exporters from different pooled sessions. What do people think?

[DavidSchinazi]

SGTM

[DavidSchinazi]

Chair: discussed in editor's meeting. We'd like to get @martinthomson 's opinion before writing a PR.

[martinthomson]

You don't have a field for the context length, which isn't technically incorrect, but I'd prefer not to rely on the TLS layer having a length field of its own so that you can delineate the context field.

Fixed-size lengths are good here as you avoid canonicalization challenges with varints, so that is good.

The similarities with TLS ensure that you can switch out QUIC for WebTransport, which seems to be a goal here that is worth explaining. Otherwise, the "label" and "context" separation only exists for that reason.

Overall, this is pretty much what we discussed on the referenced issue. I'm not seeing a ton of urgency around this feature, but what @vasilvv describes is a good approach.

[DavidSchinazi]

Chair: discussed in editor's meeting, some folks think we should remove this and punt to an extension, while others prefer to keep it. Let's discuss at 117.

[DavidSchinazi]

Chair: discussed at 117. @marten-seemann is supportive and has a use case but multiple people said this wasn't necessary. Agreement in the room that this would be implemented only in browsers due to the need for a security boundary between a layer that has access to the TLS keying material (browser) and a layer that does not (JavaScript). Right now there is no consensus to add this. @marten-seemann will take an action item to file an issue at the W3C to try to gather more use cases there. If the W3C comes back to us with a strong need for this we will revisit.

[Neustradamus]

To follow.

[DavidSchinazi]

Chair: discussed in editor's meeting. @marten-seemann have you found more supporters for this? If not we'll close this as it can always be added as an extension later.

[DavidSchinazi]

Chair: closing due to lack of interest

[Neustradamus]

@vasilvv, @martinthomson, @DavidSchinazi, @ietf-wg-webtrans, @w3c: A bad news...

[vasilvv]

Reopening, since there was some display of web developer interest recently.