On Fri, Feb 26, 2016 at 4:24 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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. That's correct. And would continue to be the case here. > 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). > I agree that there are arguably more elegant approaches if you are willing to change TLS. It seems like the argument here is that this doesn't require ay significant changes. > 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. > FWIW, this seems like it would be harmless and not difficult to implement once you had KeyUpdate (since you need to keep count anyway). -Ekr > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
