diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md
index eb1e91e05d..8a62c272c2 100644
--- a/draft-ietf-quic-tls.md
+++ b/draft-ietf-quic-tls.md
@@ -983,23 +983,31 @@ without necessarily needing to receive the first packet that triggered the
 change.  An endpoint that notices a changed KEY_PHASE bit can update keys and
 decrypt the packet that contains the changed bit.
 
+This mechanism replaces the TLS KeyUpdate message.  Endpoints MUST NOT send a
+TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate
+message as a connection error of type 0x10a, equivalent to a fatal TLS alert of
+unexpected_message (see {{tls-errors}}).
+
 An endpoint MUST NOT initiate more than one key update at a time.  A new key
 cannot be used until the endpoint has received and successfully decrypted a
 packet with a matching KEY_PHASE.
 
-A receiving endpoint detects an update when the KEY_PHASE bit doesn't match what
+A receiving endpoint detects an update when the KEY_PHASE bit does not match what
 it is expecting.  It creates a new secret (see Section 7.2 of {{!TLS13}}) and
-the corresponding read key and IV.  If the packet can be decrypted and
-authenticated using these values, then the keys it uses for packet protection
-are also updated.  The next packet sent by the endpoint will then use the new
-keys.
-
-An endpoint doesn't need to send packets immediately when it detects that its
-peer has updated keys.  The next packet that it sends will simply use the new
-keys.  If an endpoint detects a second update before it has sent any packets
-with updated keys it indicates that its peer has updated keys twice without
-awaiting a reciprocal update.  An endpoint MUST treat consecutive key updates as
-a fatal error and abort the connection.
+the corresponding read key and IV using the same variation on HKDF as
+defined in {{protection-keys}}; that is, the prefix "quic " is used in place of
+"tls13 ".
+
+If the packet can be decrypted and authenticated using the updated key and IV,
+then the keys the endpoint uses for packet protection are also updated.  The
+next packet sent by the endpoint will then use the new keys.
+
+An endpoint does not always need to send packets when it detects that its peer
+has updated keys.  The next packet that it sends will simply use the new keys.
+If an endpoint detects a second update before it has sent any packets with
+updated keys, it indicates that its peer has updated keys twice without awaiting
+a reciprocal update.  An endpoint MUST treat consecutive key updates as a fatal
+error and abort the connection.
 
 An endpoint SHOULD retain old keys for a short period to allow it to decrypt
 packets with smaller packet numbers than the packet that triggered the key