Original text:
The secret key and the nonce are values derived by calling HKDF- Expand-Label using <del> 0x656e61e336ae9417f7f0edd8d78d461e2aa7084aba7a14c1e9f726d55709169a as </del>  the secret, with labels being "quic key" and "quic iv" (protection- keys).

Reviewer comments:
Any chance we could also update the initial salt?
I was saving that for the final version, by popular demand. If you have a reason to change, then I can do that (I'll also want to update the keys for Retry in that case).
I agree with NAME Let's leave the salt update to the final version.
With Google's QUIC deployment, we're already experiencing version ossification due to middleboxes inspecting initial packets - some of our traffic is stuck on older versions of GoogleQUIC because of this. Changing the salts every time we change the version number will help remind everyone that this is not an ossified aspect of the protocol. The cost to implementors is pretty much zero. NAME out of curiosity, why the pushback?
What NAME says makes sense to me, so I would be in favor of shipping draft-29 with new salts.
I updated the salts and the test vectors in quic-go, and I can confirm that the values match.
The draft describes that a client SHOULD NOT reuse a token in different connections (URL). However, I miss the argument that the server SHOULD NOT construct the same token multiple times. This argument addresses the risks of client tracking via tokens if a deterministic approach is used to construct them.
Maybe ?
NAME do you mean already covers this?
Yes, my view is that and the corresponding mailing list thread (URL) covers this issue. They discuss about unlinkability between the tokens issued by a server.
NAME do you agree that this is (mostly) covered by ? If yes, can we close this issue and resolve it as part of ?
No, does not cover this particular point. makes the point that a network observer should not be able to derive information such as a timestamp from observed tokens. However, this issue says that the construction of the token should not be deterministic. To illustrate this problem, assume that the token is more or less the hash of the client's source address. Thus, the client receives upon repeat connections each time the same token, if its source address is identical. As a result, even if the client uses each token only a single time the corresponding connections established with these tokens can be correlated to each other by a network observer.
NAME could be modified to cover your issue? could you comment there?
NAME Ok, I will make proposals within to cover this issue.
NAME the automation failed here - this should not be moved to "Text Incorporated", it should just be closed As stated in URL, my understanding is that a token sent in a NEW_TOKEN frame SHOULD be encrypted. The only exception would be the case of the token carrying only an opaque and randomly-generated key identifier in a stateful design (i.e. a server using a key-value store to retain the information of previous connections). Otherwise, an observer can use the information contained in the token sent in an resuming connection, to correlate that connection to the previous connection that issued the token. For example, if a server includes the generation time of the token in plaintext, an observer can extract that information found in an Initial packet to nail down the connection that issued the token. While I think we might be call this an editorial issue, I think we should clarify this as a normative requirement (e.g., SHOULD). Hence bringing the discussion to the mailing list as well. Kazuho Oku

Revised text:
The secret key and the nonce are values derived by calling HKDF- Expand-Label using  <ins> 0x8b0d37eb8535022ebc8d76a207d80df22646ec06dc809642c30a8baa2baaff4c as </ins> the secret, with labels being "quic key" and "quic iv" (protection- keys).