Re: [TLS] Computation of static secret in anonymous DH

[Eric Rescorla <[e-mail]>]

On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara <
[e-mail]> wrote:

> On Wed, Jun 17, 2015 at 09:35:14AM -0700, Eric Rescorla wrote:
> > On Wed, Jun 17, 2015 at 8:05 AM, Ilari Liusvaara <
> > [e-mail]> wrote:
> >
> > > On Wed, Jun 17, 2015 at 05:56:23AM -0700, Eric Rescorla wrote:
> > > > On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara <
> > > > [e-mail]> wrote:
> > > >
> > > > > There's much newer version in ekr/tls13-spec#WIP_draft_06
> > > > > (seems to have fixed most of the mistakes in the original WIP)
> > > > >
> > > >
> > > > Don't worry, I'm sure there are plenty of mistakes left!
> > >
> > > Such as how keys for TLS exporters are derived?
> >
> > Quite possibly. Hence the WIP designation.
> >
>
> Reviewing it again after changes (e1219310a7f, Jun 25th):
>
> 1) xSS is used as direct input to HKDF-Expand, so one would presume
> it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Expand
> are supposed to be paired). HKDF-Extract does not take label nor
> length.
>
> 2) Same as above for xES.
>
> 3) Same as above for master_secret.
>
> 4) Why does master_secret derivation take xSS and xES instead of
> SS and ES directly (especially if xSS and xES are supposed to be
> HKDF-Extract outputs)?
>
> 4) Why is finished independent of ES (IIRC, it did depend on it
> in earlier version)?
>

i'm going to refer these to Hugo, as they were his suggestion.



> 5) Application data uses xES as secret. AFAICT, leads to an attack.
> Should be master_secret (IIRC, was that way in earlier version)?
>

This is a typo. Will fix.  Remember, this is a WIP branch. :)

With that said, I'd be interested in hearing what the attack is.


6) I think the key table should refer to inputs by their proper
> names, not e.g. referring to "xES" as "ES" when there is another
> thing named "ES" (that's confusing even with a note).
>

Typo. Willdo.


7) I think there should be helper function defined to do the
> label zero-padding, instead of it being just a note (just for
> clarity).


Hmm... Can you suggest text? Do you think we should do this
for the signature context as well?

-Ekr



>
> -Ilari
>