Draft: draft-ietf-quic-tls

Commentary: In this context , " newer " was confusing as the code permits the creation of the next set of packet protection keys when switching over . As the goal of the text was to ensure that old keys not be used , using that formulation avoids any confusion that might be caused from not having a reference against which to decide which is " newer " . 
 Section 6.4 : An endpoint always sends packets that are protected with the newest keys .  used for packet protection can be discarded immediately after switching to newer keys . I do get confused by the first sentence reference to " newest " key . So the previous section talks about the requirement that one retain the current and next key . If one have created the next key , then that key is newest . I do n't think this is intention , but the text can be interpret that one need to switch to the next key as soon as one is allowed if one have created it . The only question is when it is created . If I would guess the above section 6.4 sentence is to ensure that one never uses the previous key , if a key change has occurred . However , one should not be forced to switch to the next key unless the other side has switched or the key has exhausted its protection life time . However , I think the current formulation can result in that an outside attacker that can inject a packet with a toggled key - phase bit can force an endpoint to switch its key , even if the peer has n't initiated a key update . This simply by forcing it to generate it , and then have the packet integrity check to fail for the injected packet . Because now there is a newer " next key " in store . 
 Never using old keys is a nice way of putting this . I 'll make that change . 
 On the last point ( which I glossed over initially , as it relates to a different concept ) , the attacker can at best force the installation of the next set of read keys and only if the receiver is willing to do so . Flipping the key phase bit has the effect of causing a receiver to select the previous or next read keys . If the receiver generates keys on demand ( which is not a great idea , but some implementations do ... ) , then it will generate those keys . That key generation should be a one - off event ( we recommend saving keys in ) . A bit flip can not result in any change to any other state ( other than the global anti - forgery counter , which is a recent addition ) . Updates only occur as a result of successfully removing packet protection and a bit flip will cause the integrity check to fail and the packet to be dropped with no other state changes . The point about " newer " is well taken though . I did n't really think that updates to read keys could affect write keys ( that 's not how my code works ) , but as this is a lock - step protocol , that seems obvious in retrospect . 
 do these explanations plus address your issue ? Or are further text changes required ? 
 Mostly , I think one could use the previous sections discussion of " current " and " next " to clarify this . For example : OLD : An endpoint never sends packets that are protected with old keys . New : An endpoint never sends packets that are protected with old keys ( previous key ) only the current key . 
 I did that in , but somehow it slipped the net and I failed to create the pull request . Sorry about that . I 'll make the recommended change ( or something like it ) . 
 request was quite clear , so you should merge this and close the issue . I think these say the same thing , but the new text is shorter , which I always like .
Paragraph (version A):
An endpoint always sends packets that are protected with the newest
keys.  Keys used for packet protection can be discarded immediately
after switching to newer keys.
Paragraph (version B):
An endpoint never sends packets that are protected with old keys.
Only the current keys are used.  Keys used for protecting packets can
be discarded immediately after switching to newer keys.