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

From: Douglas Stebila <[email-masked]>
Date: Wed, 17 Jun 2015 07:33:31 +0000

In the DH-based draft of TLS 1.3 (https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt), how is the ServerParameters message containing the static secret SS constructed in the unauthenticated setting?

Douglas

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 17 Jun 2015 11:25:29 +0300

On Wed, Jun 17, 2015 at 07:33:31AM +0000, Douglas Stebila wrote:
> In the DH-based draft of TLS 1.3 (https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt),
> how is the ServerParameters message containing the static secret SS
> constructed in the unauthenticated setting?

There's much newer version in ekr/tls13-spec#WIP_draft_06
(seems to have fixed most of the mistakes in the original WIP)

There for anonymous setting, seemingly SS is copy of ES, and
configurations (essentially replacement of ServerParameters) can't
appear at all (because one needs a certificate to send one).

I can't figure out what to use as configurations hash part of
session hash in case there isn't assumed or negotiated
configuration (some session hashes are seemingly always that
way, especially things like the one used for handshake key
derivation).

It also does not say what master key to use for handshake
encryption key derivation. I presume tmp2.

Also, I note that seemingly if configuration private key
gets compromised, one can MITM all sessions using it at
will (it has finite lifetime, but other than that, I see
no good way to revoke).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Jun 2015 05:56:23 -0700

On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara <
[email-masked]> wrote:

> > In the DH-based draft of TLS 1.3 (
> https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt
> ),

Don't worry, I'm sure there are plenty of mistakes left!

> appear at all (because one needs a certificate to send one).

Affirmative.

> way, especially things like the one used for handshake key

It's empty, but I'll be fixing this.

> encryption key derivation. I presume tmp2.

" For handshake records, this means the ephemeral secret (ES)"

This whole section is still under active development, though.

> will (it has finite lifetime, but other than that, I see

Yes, this seems like an inherent property of anything that
authenticates with a semi-static or static DH key.

-Ekr

>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 17 Jun 2015 18:05:05 +0300

> Don't worry, I'm sure there are plenty of mistakes left!

Such as how keys for TLS exporters are derived? Trying to
search for 'export' or 'extractor' only gives changelog
entry about fixing used key...

Editor's copy says exporters use master secret (not quite
ideal).

> This whole section is still under active development, though.
 
I was thinking about avoiding using ES twice (since it is not
secured against THS-style attacks, while tmp2 is).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Jun 2015 09:35:14 -0700

On Wed, Jun 17, 2015 at 8:05 AM, Ilari Liusvaara <
[email-masked]> wrote:

> Such as how keys for TLS exporters are derived?

Quite possibly. Hence the WIP designation.

> Trying to

All key derivations include the transcript.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 26 Jun 2015 11:50:09 +0300

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

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

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Jun 2015 05:55:21 -0700

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

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

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

> thing named "ES" (that's confusing even with a note).

Typo. Willdo.

> label zero-padding, instead of it being just a note (just for

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

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 26 Jun 2015 19:54:15 +0300

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

Probably nobody uses tls-unique the wrong way, but then, nobody
probably thought somebody uses tls-extractor outputs as nonces in
TLS 1.2 (I know two (now deprecated) protocols that do that, both
took a nasty hit from THS).

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

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

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

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

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

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

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

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Jun 2015 10:08:55 -0700

Thanks for your review.

> really misuse it for that to matter). With finished just depending on

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?

> sends back (which can be quite revealing about what the 0-RTT payload

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.

> it isn't clear how to best denote it, since digitally-signed

Thanks. I'll give it a shot.

> except this doesn't seem to happen as fast as we would like. RC4, MD5

What did you have in mind for fixing this?

> uses might be ClientAuthentication and ServerAuthentication).

Yeah, worth a shot.

> having compromised some signed client's key).

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

> SHA-1 to SHA-256 and delete remark about PCs (it is throughly

I am planning to rewrite much of this section.

> parameter' (DSA is pretty much obsolete, or better, use deterministic

I would appreciate PRs for this.

> 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

---

From: Nico Williams <[email-masked]>
Date: Fri, 26 Jun 2015 13:41:29 -0500

> for TLS-Unique based on the exporter secrets?

tls-unique depends on the Finished message strongly binding the entire
transcript up to that point.  I find this elegant (despite the
resumption problem, which anyways, should be fixed by the session hash)
and easy to understand and analyze.

If the Finished message no longer has this property in 1.3 then that's a
problem for tls-unique, and we'd have to fix one or the other.  Surely
1.3 will have some handshake message that binds the transcript, and why
that wouldn't be the Finished message is beyond me (but I am missing a
lot of the 1.3 context, so please forgive and inform me).

It would be better though to move the responsibility for defining
tls-unique to the TLS 1.3 spec even if tls-unique remains unchanged.
That way 1.3 and/or future versions of TLS can specify different
constructions of tls-unique.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Jun 2015 11:47:41 -0700

> lot of the 1.3 context, so please forgive and inform me).

In general TLS 1.3 tries to derive keys from as much of the transcript
as is available. The issue with Finished is that for the cryptographic
logic reasons I indicated earlier [0], it is computes using only SS
which means that for some handshake modes it isn't tied to the
ephemeral keys. However, the exporter secret is.

> constructions of tls-unique.

This seems like a good idea.

-Ekr

[0] Hugo can explain this better than I, but as I understand it, the point
is
that SS is being used to authenticate ES via the Finished and if you
compute the Finished based on ES, then it creates a circular logic.

> o

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 26 Jun 2015 12:27:20 -0700

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

> are supposed to be paired). HKDF-Extract does not take label nor

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

​

> SS and ES directly (especially if xSS and xES are supposed to be

​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

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

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Jun 2015 12:31:01 -0700

Note: I have updated the WIP (and that's what I sent to Hugo) so it now
contains the
changes the values Hugo describes.

> the symbol MS is not used anymore)​

I intend to change this to "master_secret", but the table got too wide and
I need to figure out how to fix that :)

> stronger for use as keys and for extraction seeds.

As Hugo indicates, these are now fixed in my working copy.

-Ekr

​Hugo

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 26 Jun 2015 22:47:34 +0300

> changes the values Hugo describes.

Small nit:

master_secret= HKDF(xSS, xES, "master secret")
 
Should that be:

master_secret= HKDF(xSS, xES, "master secret", L)

(the length parameter is seemingly missing)?

Also, is that label NUL-terminated or not (I think it is)? Another
reason why I think it is not a good idea to use notes to change
meaning of explcit algorithms...

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Jun 2015 12:51:01 -0700

> (the length parameter is seemingly missing)?

Yes, thanks for the correction.

> meaning of explcit algorithms...

They are all NUL-terminated.

I'm happy to add a wrapper as you suggest, just haven't gotten to it yet.

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Mon, 29 Jun 2015 13:46:18 +0200

> They are all NUL-terminated.

Isn't this a departure from TLS1.0 up to TLS1.2?

I don't think this is a good idea...
 
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic