On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Thu, Sep 01, 2016 at 12:55:29PM -0700, Eric Rescorla wrote: > > I have created a PR for this at: > > https://github.com/tlswg/tls13-spec/pull/611 > > > > As it seems there was rough consensus for this change, I will merge this > > weekend > > absent some violent objections or direction to the contrary from the > chairs. > > > > -Ekr > > I tried to implement this, and discovered an issue: > > The client handshake traffic secret is needed for deriving client > Finished, and client application traffic secret is only needed after > that point. However, the derivation of client application traffic > secret uses handshake hash post Server Finished. > > So you either need to buffer the handshake hash value, or have two > overlapping client traffic secrets. > > Changing the client application traffic secret context to extend > up to Client Finished would solve the issue. > Hmm.... having the keys in one direction cover the client's certificate and certverify and the keys in the other direction not seems pretty sketchy. As I understand this, it's just an aesthetic issue, right? -Ekr > > Additionally: > - That would make the implementation look nicely symmetric > - Would also prevent having "not yet" keys. One can derive keys > from present state and install them immediately. > > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
