Change:
5.2. Initial packets are protected with a secret derived from the <del> Destination Connection ID field from the client's first Initial packet of the connection.  Specifically: </del> <ins> Destination Connection ID field from the client's Initial packet. Specifically: </ins> The hash function for HKDF when deriving initial secrets and keys is SHA-256 SHA.

Discussion:
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
URL 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: The initial keys stay the same for the entire connection The initial keys for encrypting/decrypting a packet are derived from the server's CID listed in that packet 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.)
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.
NAME Maybe I am wrong, but haven'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 (NAME 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.?
NAME Correct. It is also my understanding that we do 3 (not 2).
NAME So long as the backend server has to give the OCID in the TP, you need the shared format/key for the token. This won'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 don't understand the "why" of option 3.
I don'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(URL) from NAME and NAME 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 Nick) writes a PR?
Reading NAME comment on URL, 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.
NAME 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 can'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.