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

2016-03-05 Thread Ilari Liusvaara
On Sat, Mar 05, 2016 at 12:46:01AM -0800, Philip Levis wrote: > Something I think that might not have been clear is this proposal > doesn’t in any way change how KeyUpdates are generated or processed. > In that way, crossings do not matter for the protocol. However, from > an application

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

2016-03-05 Thread Philip Levis
Comments inline. > On Feb 27, 2016, at 9:53 AM, Eric Rescorla wrote: > > > > On Fri, Feb 26, 2016 at 4:24 AM, Ilari Liusvaara > wrote: > On Fri, Feb 26, 2016 at 01:27:45AM -0800, Judson Wilson wrote: > > Hello folks, > > > > How this helps: In the

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

2016-02-27 Thread Eric Rescorla
On Fri, Feb 26, 2016 at 4:24 AM, Ilari Liusvaara 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

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

2016-02-26 Thread Ilari Liusvaara
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

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

2016-02-26 Thread Judson Wilson
Hello folks, We'd like to add a field to the KeyUpdate message that represents the generation of receive traffic keys in use by the sender of the KeyUpdate message. (Our pull request: https://github.com/tlswg/tls13-spec/pull/426) How this helps: In the current draft, an endpoint that sends a