-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Key Diversity #2175
Comments
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? |
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. |
Yes, the transplanting is prevented by many things. The extension, the fact that the formats are incompatible, and key diversity. |
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 |
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. |
The 0-RTT text was written out of an abundance of caution. If:
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. |
This doesn't look right
The CH will also contain the QUIC transport parameters, so why aren't those keys different
The text was updated successfully, but these errors were encountered: