Re: [TLS] KeyUpdate and unbounded write obligations

[Eric Rescorla <[e-mail]>]

On Thu, Sep 1, 2016 at 2: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:
>

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
>