Re: [TLS] KeyUpdate and unbounded write obligations

[David Benjamin <[e-mail]>]

On Thu, Sep 1, 2016 at 5:29 PM Ilari Liusvaara <[e-mail]>
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 <
> [e-mail]>
> > 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.
>

I do rather like never splitting the DeriveTrafficKey() and UseTrafficKey()
operations. We have to hold on to an extra copy of traffic_secret_0 today
in the single-ladder version for very similar reasons. That only one set of
keys covesr the client certificate is certainly kind of weird. Although I
assume we can just analyze as if it didn't since we were clearly okay with
not including it before.

David