diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md
index 584fa1e186..b0c30b1ec2 100644
--- a/draft-ietf-quic-tls.md
+++ b/draft-ietf-quic-tls.md
@@ -1496,10 +1496,11 @@ The endpoint that initiates a key update also updates the keys that it uses for
 receiving packets.  These keys will be needed to process packets the peer sends
 after updating.
 
-An endpoint SHOULD retain old keys so that packets sent by its peer prior to
-receiving the key update can be processed.  Discarding old keys too early can
-cause delayed packets to be discarded.  Discarding packets will be interpreted
-as packet loss by the peer and could adversely affect performance.
+An endpoint MUST retain old keys until it has successfully unprotected a packet
+sent using the new keys.  An endpoint SHOULD retain old keys for some time
+after unprotecting a packet sent using the new keys.  Discarding old keys too
+early can cause delayed packets to be discarded.  Discarding packets will be
+interpreted as packet loss by the peer and could adversely affect performance.
 
 
 ## Responding to a Key Update
@@ -1603,12 +1604,13 @@ in the network.  In this case, the Key Phase bit alone can be used to select
 keys.
 
 An endpoint MAY allow a period of approximately the Probe Timeout (PTO; see
-{{QUIC-RECOVERY}}) after a key update before it creates the next set of packet
-protection keys.  These updated keys MAY replace the previous keys at that time.
-With the caveat that PTO is a subjective measure - that is, a peer could have a
-different view of the RTT - this time is expected to be long enough that any
-reordered packets would be declared lost by a peer even if they were
-acknowledged and short enough to allow for subsequent key updates.
+{{QUIC-RECOVERY}}) after receiving a packet that uses the new key generation
+before it creates the next set of packet protection keys.  These updated keys
+MAY replace the previous keys at that time.  With the caveat that PTO is a
+subjective measure - that is, a peer could have a different view of the RTT -
+this time is expected to be long enough that any reordered packets would be
+declared lost by a peer even if they were acknowledged and short enough to
+allow for subsequent key updates.
 
 Endpoints need to allow for the possibility that a peer might not be able to
 decrypt packets that initiate a key update during the period when it retains old
@@ -1617,9 +1619,9 @@ after receiving an acknowledgment that confirms that the previous key update was
 received.  Failing to allow sufficient time could lead to packets being
 discarded.
 
-An endpoint SHOULD retain old read keys for no more than three times the PTO.
-After this period, old read keys and their corresponding secrets SHOULD be
-discarded.
+An endpoint SHOULD retain old read keys for no more than three times the PTO
+after having received a packet protected using the new keys. After this period,
+old read keys and their corresponding secrets SHOULD be discarded.
 
 
 ## Limits on AEAD Usage {#aead-limits}