Draft: draft-ietf-quic-tls

Commentary: Some of this is just forward reference , but it does need a little more context . Also , there was a missing word . 
 This also no ? 
 said : 
 I 'll roll this into the change for as it relates to the same basic text . I like the " promoting " idea , though I 'm not going to go back and rewrite everything to use it . Here , the important thing is to have words for current , next , and " subsequent next " to avoid making this more confusing than necessary . I think that I got it . 
 said : 
 I can see an obvious missing word in there at a minimum . I can see some opportunities for clarification here though , so I 'll give it a go . Breaking the ordering dependencies between sections is tricky though . It might just be that we need a little redundancy . 
 This is a big help ; thank you !
Paragraph (version A):
The process of creating new packet protection keys for receiving
packets could reveal that a key update has occurred.  An endpoint MAY
perform this process as part of packet processing, but this creates a
timing signal that can be used by an attacker to learn when key
updates happen and thus the value of the Key Phase bit in certain
packets.  Endpoints MAY instead defer the creation of the next set of
receive packet protection keys until some time after a key update
completes, up to three times the PTO; see old-keys-recv.
Paragraph (version B):
The process of creating new packet protection keys for receiving
packets could reveal that a key update has occurred.  An endpoint MAY
generate new keys as part of packet processing, but this creates a
timing signal that could be used by an attacker to learn when key
updates happen and thus leak the value of the Key Phase bit.
Paragraph (version B):
Endpoints are generally expected to have current and next receive
packet protection keys available.  For a short period after a key
update completes, up to the PTO, endpoints MAY defer generation of
the next set of receive packet protection keys.  This allows
endpoints to retain only two sets of receive keys; see old-keys-recv.
Paragraph (version A):
An endpoint MAY allow a period of approximately the Probe Timeout
(PTO; see 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.
Paragraph (version B):
An endpoint MAY allow a period of approximately the Probe Timeout
(PTO; see QUIC-RECOVERY) after promoting the next set of receive keys
to be current before it creates the subsequent 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 a peer to initiate further key updates.