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
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
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
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
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