Draft: draft-ietf-quic-tls

Commentary: This was implied , but not explicit previously . 
 I think this also needs to change the first sentence that currently says " Initial packets are protected with a secret derived from the Destination Connection ID field from the client ’s first Initial packet of the connection . " If we 're attempting to describe the behavior that people currently have implemented ( where Initial keys change on a Retry packet but nothing else ) , the sentence I 've quoted above is false . 
 OBE 
 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 , it sounds like an Initial sent in response to a Retry is still the same connection . ) I think there are 3 options for behavior : initial keys stay the same for the entire connection initial keys for encrypting / decrypting a packet are derived from the server 's CID listed in that packet 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 . ) 
 1 and 2 are the clearest contracts and I slightly prefer 1 as well . 3 is odd and very unintuitive to me . 
 I think 1 is probably the best . I believe it would remove the need to include the original CID in the transport parameters as well , in the Retry scenario . 
 Maybe I am wrong , but have n't we had interop based on the understanding that the 2 is the correct way ( i.e. the " S " column of the interop matrix ) ? IIUC , the discussion is about " cryptographic handshake message " ( i.e. ClientHello transmitted as the payload of the CYRPTO frame ) being consistent . Not about the key that encrypts ( obfuscates ) the frames . One practical issue with option 1 is that it requires the server and the issuer of the Retry token to share the format of the Retry token ( as well as a secret key to extract ODICID from the token in certain designs ) . IIRC , our previous consensus is to permit people to install DDoS mitigation boxes that issue Retry packets , without requiring such coordination between those mitigation boxes and the servers being protected ( am I correct ? ) 
 My understanding is that we interoped on the key being derived from the new DCID ( from the client ’s perspective ) on the Initial packet , so that would be 3 . ? 
 Correct . It is also my understanding that we do 3 ( not 2 ) . 
 So long as the backend server has to give the OCID in the TP , you need the shared format / key for the token . This wo n't change that . 
 This is already stated in a different section . In , it says : 
 Yes . Right now we have 3 , though not exactly as stated . It is 
 Are editorial clarifications needed here ? 
 At the minimum , the first sentence of the " Initial Secrets " section needs to be revised . I 'd prefer to understand the design rationale for when initial keys change ( and possibly incorporate that into the edit ) . Right now I do n't understand the " why " of option 3 . 
 I do n't believe that we have any responsibility to document " why " for anything . In this case , my understanding is that Reset is intended to be largely stateless . If it were stateless , then the token would need to carry the original destination connection ID ( or the derived key ) , and that would need to be extracted before the packet could be processed . 
 +1 
 Documenting " why " some choices were made is not required , but it helps readers better understand the properties of the protocol , and helps spec contributors not have the same conversations every few months . The retry token already needs to carry the original destination connection ID because the server MUST include it in the transport parameter . 
 This is marked as editorial , but 3 seems like the most non - obvious design choice , and it 's not clear we intended to make that choice . If extracting the original CID is potentially too difficult for some , why not 2 , which only uses local state to process Initial packets ? 
 Of note , in section 2.6 of the new authenticated handshake draft ( ) from and on protection Initials it says : " The Destination Connection ID of the Initial packet MUST be set to the value specified by the Retry packet , however the keys for encrypting and authenticating the packet MUST continue to be the original ones . " This aligns with the first option . It seems like the first option also allows us to remove a transport param , which is a nice property . Given that , is anyone actively opposed to the first option assuming someone else(ie : myself or  ) writes a PR ? 
 Reading comment on , I think that the computation cost of mounting a DoS attack would change if we are to retain the original Initial secrets after Retry , as proposed in . In the current design , a server can use Retry packets to enforce clients to do equal amount of HKDF extractions , as the CIDs found in Retry packets update the Initial secrets . However , if we adopt , the clients will given the freedom to choose the Initial key regardless of if Retry is used . That might open new attack vectors . For example , a DDoS attacker might send Initial packets that carry the same DCID ( or a small set of DCIDs ) from multiple addresses , receive Retry tokens , then send back Initial packets carrying the correct tokens and CIDs . The clients can use the precomputed Initial secrets when sending back the Initial packets , the client . I am not sure how important this kind of attack is , but I think we need to make sure that the change of computation cost is OK . 
 has a design - level change for this in that I think is a good idea to talk about . 
 One new point that came up in the discussion of is that if every packet is self - contained(ie : option 2 ) , it would be possible for the server to send a CONNECTIONCLOSE to terminate a handshake that is doomed to failure quickly , opposed to waiting for the handshake to timeout . If my PR is accepted , the server would not be able to send a CONNECTIONCLOSE . 
 Discussed in Cupertino ; we believe that we should clarify to option 3 ( i.e. , mt 's ) . 
 For the record , the two arguments that carried this were a ) everyone has already implemented , and b ) you ca n't send CONNECTION_CLOSE if you keep the keys the same . Mix to taste . 
 This is fine for clarifying the current state of affairs . I think we need to come to a conclusion on , however , whether that will stay the case .
Paragraph (version B):
The secrets used for protecting Initial packets change when a server
sends a Retry packet to use the connection ID value selected by the
server.  The secrets do not change when a client changes the
Destination Connection ID it uses in response to an Initial packet
from the server.