Initial secrets do not change after Retry

draft-ietf-quic-tls.md

@@ -771,8 +771,8 @@ TLS 1.3 (see {{initial-secrets}}).
 ## Initial Secrets {#initial-secrets}
 
 Initial packets are protected with a secret derived from the Destination
-Connection ID field from the client's first Initial packet of the
-connection. Specifically:
+Connection ID field from the client's first Initial packet of the connection.
+Specifically:
 
 ~~~
 initial_salt = 0x7fbcdb0e7c66bbe9193a96cd21519ebd7a02644a
@@ -804,17 +804,18 @@ 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 or save
+the original connection ID in the Retry token.  The initial connection ID
+is needed by a server to reconstruct packet protection keys and so that it
+can produce the correct value for the original_connection_id transport
+parameter.
+
 {{test-vectors-initial}} contains test vectors for the initial packet
 encryption.
 
-Note:
-
-: The Destination Connection ID is of arbitrary length, and it could be zero
-  length if the server sends a Retry packet with a zero-length Source Connection
-  ID field.  In this case, the Initial keys provide no assurance to the client
-  that the server received its packet; the client has to rely on the exchange
-  that included the Retry packet for that property.
-
 
 ## AEAD Usage {#aead}