Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field

[Ilari Liusvaara <[e-mail]>]

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