[quicwg/base-drafts] Do Initial secrets change after Retry packet? (#2823)

[Nick Harper <[e-mail]>]

https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.5.2 states that "Initial packets are protected with a secret derived from the Destination Connection ID field from the client’s first Initial packet of the connection." This sounds like a second Initial packet from the client (in response to a server's Retry) would still be encrypted using keys derived from the original DCID instead of a potentially new DCID. However, that section later mentions the client creating an Initial packet in response to a Retry packet and the DCID is selected by the server.

These two statements should be reconciled to clarify that either the initial keys stay the same for the entire connection, or that initial keys can change. (From the discussion in #2180, it sounds like an Initial sent in response to a Retry is still the same connection.)

I think there are 3 options for behavior:
1. The initial keys stay the same for the entire connection
2. The initial keys for encrypting/decrypting a packet are derived from the server's CID listed in that packet
3. The initial keys are derived from the client's first DCID, unless the server sends a Retry packet, after which the initial keys are re-derived from the server's new DCID.

These options are in my preference order.

My understanding for why initial keys change after a Retry is to support servers handling Retry statelessly. A server should still be able to use the original DCID for initial key derivation in this case because the ODCID is needed for transport parameters, and the retry token is sent in the clear in the Initial packet, so the server can recover it from the token.

Option 2 lets the keys change, but follows a simpler principle for what the keys are. When processing a packet for a connection, the information to encrypt or decrypt it is all self-contained - there is no additional connection state to check whether a new encrypter or decrypter is needed because an Initial packet was sent/received after a Retry packet.

One of the reasons why option 3 seems odd to me is that there are multiple ways the server's CID can change between Initial packets on the same connection, but Retry packets are the only case where we change the initial keys. (E.g. consider from a client's perspective sending a second ClientHello in response to a Retry packet has the initial keys change, but sending it in response to a HelloRetryRequest keeps the keys the same, even though the server likely changed its CID in the Initial packet where it sent the HRR.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2823