Key Diversity

[ekr]

This doesn't look right

In using TLS, the central key schedule of TLS is used.  As a result of the TLS
handshake messages being integrated into the calculation of secrets, the
inclusion of the QUIC transport parameters extension ensures that handshake and
1-RTT keys are not the same as those that might be produced by a server running
TLS over TCP.  However, 0-RTT keys only include the ClientHello message and
might therefore use the same secrets.  To avoid the possibility of
cross-protocol key synchronization, additional measures are provided to improve
key separation.

The CH will also contain the QUIC transport parameters, so why aren't those keys different

[martinthomson]

Yes, but a TLS/TCP server will ignore those, so it's the transport parameters in EncryptedExtensions that ensure diversity.

This is defense is depth, as it says. What do you think we should say instead?

[ekr]

I'm not sure, because I'm not really sure what this is trying to say. Concretely, the concern seems to be that it would be possible to somehow transplant 0-RTT QUIC data onto a TLS-over-TCP connection or vice versa? However, I don't believe this is actually possible even if the same keys are used because QUIC long header packets are incompatible cryptographically with TLS records.

[martinthomson]

Yes, the transplanting is prevented by many things. The extension, the fact that the formats are incompatible, and key diversity.

[martinduke]

I agree with @ekr. The key separation design is fine, but the sentence about 0-RTT doesn't make any sense. I would delete the sentence about 0-RTT, so it would read thus:

In using TLS, the central key schedule of TLS is used. As a result of the TLS
handshake messages being integrated into the calculation of secrets, the
inclusion of the QUIC transport parameters extension ensures that keys are
not the same as those that might be produced by a server running
TLS over TCP. To further diminish the possibility of cross-protocol key
synchronization, additional measures are provided to improve key separation.

[kazuho]

Yeah, I think we can argue that it's not just about using something other than TLS over TCP. We use the protocol name as a prefix because we believe that every protocol needs to use different keys.

I am fine with @martinduke's text, but we can be more clear about the rationale.

[martinthomson]

The 0-RTT text was written out of an abundance of caution. If:

1. A server won't accept 0-RTT without successfully processing the ClientHello.
2. A QUIC server won't successfully process a ClientHello and accept if the quic_transport_parameters extension is absent.
3. A TLS over TCP server might successfully process a ClientHello and accept 0-RTT if the quic_transport_parameters extension is present.

You get into a situation where the separation we provide for keys and the change in record header format is all that prevents QUIC 0-RTT from being played out as TLS/TCP 0-RTT. I mean, that seems like plenty, it just depends on how much spare paranoia you have.