On Fri, Feb 26, 2016 at 01:27:45AM -0800, Judson Wilson wrote: > Hello folks, > > How this helps: In the current draft, an endpoint that sends a KeyUpdate > message and later receives a KeyUpdate message cannot know whether the > other side has actually updated its receive keys. The two messages may have > been generated independently and crossed in flight. Putting a > receive_generation field in the KeyUpdate message lets an endpoint confirm > that the other side has received and acted upon an earlier KeyUpdate > message.
Well, the KeyUpdates are designed to be asynchronous so that the other end does not need to know if the other has acted on KeyUpdate. > One way for a client to grant delayed read-only access in TLS 1.3 is with a > "rotate and release." The client starts by sending a KeyUpdate. Later, > after all traffic keys from the previous generation have been superseded on > both sides, the client releases the (superseded) traffic keys to the > middlebox. The middlebox can use the keys to decrypt the previous > generation of ciphertext, without danger of compromising the integrity of > the session. The challenge is that an endpoint can't safely release its old > send keys until it knows that the other side has updated its receive keys. > Hence the receive_generation field. There are better (and less broken) ways to do this kind of thing (involving two MACs). > We think this is a pretty lightweight way to resolve the ambiguity from > KeyUpdates crossing in flight; it doesn't add any blocking, waiting, or > extra rounds or messages. Thanks in advance for any feedback. The KeyUpdate design is so that crossings don't matter. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
