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

[Hugo Krawczyk <[e-mail]>]

I would prefer to have a more stable version of the draft to comment on
these design choices/logic but let me refer to some of your questions below
(particularly as I  may not be available for responding in the next few
days).

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.
>

​Logically, xSS is an extracted version of SS and could have been derived
as
xSS = HKDF-Extract(0,SS)​. Same would apply to xES.
The reason we apply a full HKDF in these derivations (i.e., adding the
Expand part after Extract) is that in cases where SS=ES (e.g. in PSK mode
without PFS) doing just Extract would result in xES=xSS which is bad for
the derivation of master_secret (it would set the seed and key material of
HKDF in the derivation of master_secret to the same value hence requiring
stronger assumptions on HKDF, e.g. being an idealized random oracle).
By running through the additional expand with different labels we get xSS
and xES to be computationally independent (i.e., the outputs of a prf with
the same key but computed on different inputs).


> 2) Same as above for xES.
>

​Same logic/answer as above.​


>
> 3) Same as above for master_secret.
>

​We could have defined
master_secret = HKDF-Extract(xSS, xES)
but we used full HKDF here for uniformity with the derivation of xES and
xSS.
A
​lso, in this way we do not have the use of HKDF-Extract in the draft at
all, just full HKDF or HKDF-Expand (the latter being essentially a PRF)
which adds to simplicity.

​

>
> 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)?
>

​Since we already extracted the entropy of SS and ES into the keys xSS and
xES it is better to directly use the latter as keys rather than the
non-uniform SS and ES.
​


>
> 4) Why is finished independent of ES (IIRC, it did depend on it
> in earlier version)?
>

Two important reasons.
1. Only SS can authenticate the handshake as it is the only element to
involve the server's (semi) static private key.
2. One of the main elements to be authenticated by the server (via the
Finished message) is its key share  - deriving the key for the Finished
message calculation from ES would create a circularity issue in the logic
of the derivation.

Note that the derivation of application keys (and other key material
remaining after the end of the handshake) do involve both SS and ES, but
there it makes sense since this comes after authentication and has the goal
of secrecy of the application keys (particularly to resist future attacks
upon compromise of long-term secret keys, namely, when PFS is required).


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

​Application data uses master_secret: See table before 7.2.1 where
application keys are derived from MS (should be denoted as master_secret;
the symbol MS is not used anymore)​



>
> 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).
>

​The table is correct by referring to xSS and xES.
These are different values than SS and ES.
As their name indicates they are extracted versions of the latter, hence
stronger for use as keys and for extraction seeds.
​

​Hugo
​


> 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).
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>