diff --git a/ianswett-initial-secrets-constant/draft-ietf-quic-tls.html b/ianswett-initial-secrets-constant/draft-ietf-quic-tls.html index 2ad7b7bf60..61d1b447a6 100644 --- a/ianswett-initial-secrets-constant/draft-ietf-quic-tls.html +++ b/ianswett-initial-secrets-constant/draft-ietf-quic-tls.html @@ -951,7 +951,7 @@
The connection ID used with HKDF-Expand-Label is the Destination Connection ID in the Initial packet sent by the client. This will be a randomly-selected value unless the client creates the Initial packet after receiving a Retry packet, where the Destination Connection ID is selected by the server.
The value of initial_salt is a 20 byte sequence shown in the figure in hexadecimal notation. Future versions of QUIC SHOULD generate a new salt value, thus ensuring that the keys are different for each version of QUIC. This prevents a middlebox that only recognizes one version of QUIC from seeing or modifying the contents of packets from future versions.
The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for Initial packets even where the TLS versions offered do not include TLS 1.3.
-The secrets used for protecting Initial packets do not change during the connection, even though the destination connection ID in client Initial packets changes after receiving a Retry. A server that sends a Retry therefore needs to either remember the original connection ID and Initial protection keys or save the original connection ID in the Retry token.
+The secrets used for protecting Initial packets do not change during the connection, even though the destination connection ID in client Initial packets changes after receiving a Retry. A server that sends a Retry therefore needs to either remember the original connection ID protection keys or save the original connection ID in the Retry token.
Appendix A contains test vectors for the initial packet encryption.