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

[Eric Rescorla <[e-mail]>]

Thanks for your review.

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

> On Fri, Jun 26, 2015 at 05:55:21AM -0700, Eric Rescorla wrote:
> > On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara <
> > [e-mail]> wrote:
> >
> > > 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.
>
> Also, TLS 1.2 had tls-unique also be secret (but one would have to
> really misuse it for that to matter). With finished just depending on
> SS, secrecy might fail.
>

As I understand it, there are cryptographic logic reasons for this (again,
I'll defer to Hugo here). Maybe we should just define a new value
for TLS-Unique based on the exporter secrets?



> > > 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.
>
> Pretty weak one, but replaying 0-RTT and then decoding what the server
> sends back (which can be quite revealing about what the 0-RTT payload
> was).


Sorry, I'm still not seeing how this works. If you replay 0-RTT, then don't
you by definition not know the original client DHE share (otherwise, why
replay), so how do you decrypt? Maybe I'm just being stupid here.



> 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?
>
> Maybe something like:
>
> HKDF-Extract-Label(secret, label, seed, length) =
>     HKDF-Extract(secret, label + "\0" + seed, length)
>
> Where label is ASCII label with no NUL bytes and "\0" is the NUL
> byte.
>
> And then use that.
>
>
> Might be worthwhile doing for digital signatures as well, but
> it isn't clear how to best denote it, since digitally-signed
> works as a macro.
>

Thanks. I'll give it a shot.



>
> Some more stuff:
>
> 8) Client and Server certificate verify sign hash of handshake (using
> prf-hash) but don't indicate what hash was used. Can have nasty effects
> if the prf-hash is ever really broken and replacement has the same
> bitlength (yes, we know that broken hashes should be de-implemented,
> except this doesn't seem to happen as fast as we would like. RC4, MD5
> and EXPORT anybody?).
>

What did you have in mind for fixing this?



> 9) Might make sense to replace the early_data_allowed in
> ServerCofiguration with a bitfield listing acceptable uses (some other
> uses might be ClientAuthentication and ServerAuthentication).
>

Yeah, worth a shot.


10) "Finally, note that if the server key is compromised, and client
> authentication is used, then the attacker can impersonate the client
> to the server (as it knows the traffic key)." ... How does that work?
> I tried to figure that out, the problem I hit was that I couldn't
> figure out how to compute ES on server side of MITM (without also
> having compromised some signed client's key).
>

This was pointed out to me by Kartik so maybe I'm



> 11) Section "Random Number Generation and Seeding". Maybe change
> SHA-1 to SHA-256 and delete remark about PCs (it is throughly
> obsolete).


I am planning to rewrite much of this section.




12) "Implementation Pitfalls". Add rejecting incorrect sequence
> of handshake message types. There have been _multiple_ catastrophic
> security failures from getting this wrong.
>
> 13) 'the DSA "k" parameter'. Maybe change that to 'the ECDSA "k"
> parameter' (DSA is pretty much obsolete, or better, use deterministic
> ECDSA).
>

I would appreciate PRs for this.


14) 'In order to allow servers to readily distinguish between
> messages sent in the first flight and in the second flight (in
> cases where the server rejects the EarlyDataIndication extension),
> the client MUST send the handshake messages as content type
> "early_handshake"' ...  How does that work? Without explicit
> end of transmission incidation, the server doesn't know when
> to send ServerHello, and it needs to know that in order to
> properly lay out its session_hash (and not including those in
> session_hash needs _serious_ analysis)
>

There are two cases:
1. You accept the 0-RTT, in which case you process them and then
include them in the session hash.
2. You reject the 0-RTT, in which case you can't even decrypt them
and then you don't include them in the session hash but instead
send a ServerHello right away.

With that said, I still haven't implemented this part (WIP!) and so
am not totally sure it works. Doe that make sense?

-Ekr