On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote: > On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > 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?
I don't think this is just aesthetic issue: - If you derive the traffic secret at the moment the right hash is available, you need to stash the traffic secret for later (one can't overwrite the existing one, since you will need that for ClientFinished). - If you derive the traffic secret just before use, you need to have saved the hash value used for derivation, since the ClientFinished (and possibly Certificate(Verify)) has altered it. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
