On Thu, Sep 1, 2016 at 2:29 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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: > Perhaps I should have said "minor implementation inconvenience" - 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). > Yes, but this was already true for handshake_secret, no? -Ekr - 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
