Subject: [TLS] Requiring that (EC)DHE public values be fresh

From: Adam Langley <[email-masked]>
Date: Thu, 29 Dec 2016 09:37:39 -0800

https://github.com/tlswg/tls13-spec/pull/840 is a pull request that
specifies that (EC)DH values must be fresh for both parties in TLS
1.3.

For clients, this is standard practice (as far as I'm aware) so should
make no difference. For servers, this is not always the case:

Springall, Durumeric & Halderman note[1] that with TLS 1.2:
  ∙ 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more
    than a day.
  ∙ 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.

Since this defeats forward security, and is clearly something that
implementations of previous versions have done, this change
specifically calls it out as a MUST NOT. Implementations would then be
free to detect and reject violations of this.

This does have a cost because it also excludes the reasonable practice
of amortising public value generation over all connections for a few
seconds. The draft could attempt to specify a precise, maximum
duration for reuse but that is more complex and no value is clearly
optimal.

Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse
values and manage fine today. The generation of (EC)DH public values
is also a fixed-based operation and thus can be much faster than DH
key-agreement.

Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling
TLS connections to be decrypted and monitored by a middlebox. TLS is
not designed to be decrypted by third-parties—that's kind of the
point. Thus anyone doing this should not be surprised to hit a few
MUST NOTs and, potentially, to have to configure implementations to
allow such a deployment.

[1] “Measuring the Security Harm of TLS Crypto Shortcuts”, IMC 2016,
pages 33–47, section 4.4. https://dl.acm.org/citation.cfm?id=2987480
[2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Dec 2016 18:15:24 +0000

Hiya,

>   ∙ 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.
...

As an individual, I'd be in favour of this change but reading
over [1], section 5, I wondered if we'd analysed the effects of
0rtt/replayable-data with that kind of cross-domain re-use in mind?
The situation being where session ID based caches or session ticket
equivalents in tls1.3 are shared over multiple domains.

I don't recall this being explicitly considered, but maybe that's
just me forgetting. And hopefully the analysis is that such re-use
doesn't enable broader replay of early data, but there may be
something worth a mention in the tls1.3 spec, e.g. that there may
be linkages between the duration for which entries are maintained
in resumption and replay detection caches.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Dec 2016 10:38:54 -0800

On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell <[email-masked]
> wrote:

> in resumption and replay detection caches.

This question seems essentially orthogonal to the question of ECDHE key
reuse
because even if you use the same ECDHE key in perpetuity you get unique
traffic keying material for each connection.

-Ekr

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Dec 2016 18:50:24 +0000

> traffic keying material for each connection.

Fair enough, I probably should've started a new thread so have
done that now.

S

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Dec 2016 11:08:31 -0800

On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell <[email-masked]

> Fair enough, I probably should've started a new thread so have

Currently TLS 1.3 forbids *both* 0-RTT and resumption if the SNI changes:
https://tlswg.github.io/tls13-spec/#NewSessionTicket

"Any ticket MUST only be resumed with a cipher suite that has the same KDF
hash as that used to establish the original connection, and only if the
client provides the same SNI value as in the original connection, as
described in Section 3 of [RFC6066]
<https://tlswg.github.io/tls13-spec/#RFC6066>."

We have discussed relaxing that restriction, specifically to allow the
following case:

- Client connects to server with SNI=A and the server supplies a cert with
SNI=A, B
- Client reconnects to server and tries to resume with SNI=B

See PR: https://github.com/tlswg/tls13-spec/pull/777.

However, the general consensus was to leave this out of the base spec,
though we
might supply an enhancement for that later (and potentially slightly soften
the above
language to foreshadow such an enhancement).

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Thu, 29 Dec 2016 20:28:45 +0100 (CET)

Adam Langley wrote:
>   ? 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more
>     than a day.
>   ? 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.
> 

While you may have good intentions, the idea "and reject violations of this"
sounds like a bad idea to me.

First of all, forward secrecy is equally defeated by TLS session caching
(traditional as well as session tickets), and the effect of rfc5077
TLS session tickets is likely at least a magnitude worse--and cannot
be "fixed" by clients purging the tickets earlier.

Reuse of DHE values should not come as a surprise, PFS with DHE is
prohibitively expensive with 2048+ bit ephemeral keys.  DHE in TLS has
been well known to be fatally flawed (publicly known since the issue
was raised by Yngve on the TLS ietf mailing list in 2007).
  https://www.ietf.org/mail-archive/web/tls/current/msg01647.html

Since Sun/Oracle hardwired DHE to at most 1024 bits up to JavaSE 7,
i.e. on Billions on devices out there, DHE in TLS is a very dead horse.

Ephemeral ECDHE values should be much less painful performance-wise,
but may happen to accidentally share the same properties as DHE values.
Potentially, the (EC)DHE keypairs are (mis-)managed above the TLS stack,
instead of entirely within--in which case this would not be the fault of the
TLS implementation code, but of the TLS implementation API (design).

Now what does it mean when a _client_ that happens to connect to one
of these 14.4% Alexa top 1M sites that reuse ECDHE values, notices a
reuse of ECDHE on a repeated full handshake (which will not happen
immediately due to session caching&resumption).  This would result
is random handshake failures (client aborting the TLS handshake).
The server doesn't know why the client chokes, only the client can
decided to retry, but this is unlikely to affect the servers approach
to reusing the (EC)DHE value at all.

So the only thing this will cause is headaches to users and support
folks.  It will *NOT* improve the security by one iota.

If you want to improve something, then specify how to obtain the
desired behaviour, not how to panic and choke.

-Martin

---

From: Adam Langley <[email-masked]>
Date: Thu, 29 Dec 2016 11:36:09 -0800

> be "fixed" by clients purging the tickets earlier.

That is true in TLS 1.2, but one of the things that have been addressed in 1.3.

> i.e. on Billions on devices out there, DHE in TLS is a very dead horse.

Again, true in 1.2 but 1.3 has fixed the groups to stronger values.
Also, the key-generation of DHE is significantly cheaper than the
key-agreement so ephemeral values might be more reasonable then
benchmarks suggest.

As noted, I think specifying a maximum caching duration is plausible.
(Google servers cache QUIC X25519 values for 60-seconds, for example.)
But I'm worried about an endless discussion about how long is too long
(or long enough).

> to reusing the (EC)DHE value at all.

The idea is to establish this in clients early in the life of 1.3 so
that the pressure is enough to keep the ecosystem clean. I don't think
that enforcing it in versions prior to 1.3 is viable.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Thu, 29 Dec 2016 14:45:53 -0800

>> >> equivalents in tls1.3 are shared over multiple domains.

I think there is the following interaction:

Given two servers, S1 and S2, which are nominally s1.example.com and
s2.example.com, but which both have a *.example.com cert and share
ticket keys:

An attacker could redirect a 0-RTT handshake that was destined to S1
and feed it to S2. If S2 ignores the SNI value (common) it could
accept and process the 0-RTT data even though it was destined for S1.

However, in that case TLS 1.2 is probably also affected because S2
would likely process a 1.2 handshake that was destined to S1 as well.
(Even without a shared ticket key or session cache.) See
http://antoine.delignat-lavaud.fr/doc/www15.pdf for more.

Cheers

AGL

---

From: Brian Smith <[email-masked]>
Date: Thu, 29 Dec 2016 14:29:06 -1000

> duration for reuse but that is more complex and no value is clearly

We should brainstorm the unintended negative consequences of this.

It would make self-hosting a small that can survive a spike in traffic
("slashdot effect") more difficult, thus encouraging sites to use
CDNs, which decrease the integrity, confidentiality, and privacy
properties of all connections between the client and the origin
server. Unfortunately I don't know how to quantify that.

Another unintended consequence is that it makes the PSK modes
relatively more attractive. For some very small devices doing ECDH
agreement on every connection and only doing a occasionally doing a
ECDH keygen could be at the edge of their performance/power limits,
and needing to do the ECDH keygen for every connection could easily
make using ECDH prohibitive. OTOH, we don't want these devices to use
have a fixed ECDH key burned into their ROM, or similar, either.

Another unintended consequence is that it makes resumption (formulated
as a sort of server-generated PSK in TLS 1.3) more necessary. Although
many implementations will probably implement resumption, I think there
are a lot of cases where one might prefer to avoid implementing and/or
enabling it. Also, even when it is enabled, making ECDH more expensive
relative to PSK/resumption would encourage building more complex
server software to distribute PSKs across machines. And/or the server
may choose to reuse PSKs longer. And/or the server may choose to use
the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I
can't quantify the effect here.

> is also a fixed-based operation and thus can be much faster than DH

According to the paper, a large majority of servers in the Alexa top
1M are reusing keys. That 14.4% number is a fraction of the 80%
servers consistently in the Alexa top 1M that use browser-trusted
certificates and that use ECDHE. IIUC, approximately 20% of servers in
the Alexa top 1M that use browser-trusted certificates are using RSA
key exchange, which means they are also reusing the same key for every
connection. Also, according to the paper, more than half of servers
aren't using TLS or aren't using browser-trusted certificates, which
means that web browser connections to them are likely using the same
NULL key.

Also, the Alexa top 1M isn't representative of every use of TLS, but
rather only one kind of application.

> MUST NOTs and, potentially, to have to configure implementations to

The (presumably) accidental reuse of keys for long periods of time is
bad, and this MitM idea is even worse. But, if reuse were made a MUST
NOT, wouldn't such systems just use a different, perhaps worse, more
complex, and undetectable mechanism, like the one Dan Brown suggested
in the earlier thread? I think we should assume that while we may be
able to help prevent the former accidental badness with such a rule,
such a mechanism probably isn't going to have much effect on the
latter intentional badness.

With all this in mind, absent other information. In the case of
servers hosting websites, I do think a limit of less than a minute is
reasonable. However, I think for the small device (IoT) case, the
limit should be longer, perhaps even hours.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 30 Dec 2016 14:44:20 +0200

> accept and process the 0-RTT data even though it was destined for S1.

Sounds like standard-issue default-vhost attack (which are sadly
common security issues in https://).
 
> http://antoine.delignat-lavaud.fr/doc/www15.pdf for more.

You mean redirecting full handshake meant for s1.example.com to
s2.example.com? Or redirecting a TLS 1.2 resumption handshake?

Also, wonder how many servers don't check for SNI when resuming...

-Ilari

---

From: Richard Barnes <[email-masked]>
Date: Fri, 30 Dec 2016 09:24:06 -0500

> >> equivalents in tls1.3 are shared over multiple domains.

FWIW, we've been working on separating session caches at a
finer-than-domain-name level in Firefox, in support of allowing users to
set tracking boundaries.

https://bugzilla.mozilla.org/show_bug.cgi?id=1316283
https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/
https://www.torproject.org/projects/torbrowser/design/#identifier-linkability

--Richard

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Dec 2016 14:43:55 +0000

Hiya,

> https://tlswg.github.io/tls13-spec/#NewSessionTicket

What I'm wondering is if we're maybe missing a server-side check
on that, with the possible attempted attack of a 0rtt replay in
mind. E.g. a MUST check for the server that SNI is the same as for
initial h/s before processing early data, (as is done for ALPN now)
and/or some guidance about what might not be an obvious relationship
between any 0rtt replay detection mechanisms and session ticket
equivalents.

> See PR: https://github.com/tlswg/tls13-spec/pull/777.

I'd wonder if that optimisation is really worthwhile, esp if it
opens the door wider to 0rtt replay. (And it seems like it'd be
somewhat complex to take advantage of the optimisation anyway.)

> However, the general consensus was to leave this out of the base spec,

Seems right.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Dec 2016 08:14:57 -0800

On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell <[email-masked]>
wrote:

> equivalents

I believe that the text I quote below already requires that check. The
reason
it's there and not in the 0-RTT text is that it is a requirement on
resumption
which itself is a requirement for 0-RTT. The ALPN check is an explicit 0-RTT
requirement but not a resumption requirement.

I.e.,
Can resume only if SNI is equal
Can accept 0-RTT only if (resumed && ALPN is equal)

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Dec 2016 16:17:05 +0000

> Can accept 0-RTT only if (resumed && ALPN is equal)

Fair enough. I didn't read enough text to get that clearly
I guess, which is my fault:-)

Thanks,
S.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 30 Dec 2016 19:21:36 +0200

> Can accept 0-RTT only if (resumed && ALPN is equal)

Actually, AFAICT all types of PSKs can be used for 0-RTT if all the
needed data is provisioned. But AFAICT only dynamically provisioned
PSKs have SNI requirements.

So statically provisioned ("external") PSKs AFAICT can do 0-RTT across
SNI values.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Dec 2016 09:56:18 -0800

> So statically provisioned ("external") PSKs AFAICT can do 0-RTT across

Yes, I think that would be permitted by this text, though that's just a
result of bad writing,
which would be resolved by saying that you must only accept a PSK (rather
than
resume) if the SNIs are equal.

-Ekr

---

From: Bill Frantz <[email-masked]>
Date: Fri, 30 Dec 2016 11:41:41 -0800

> I guess, which is my fault:-)

If you didn't read enough, is this a mistake that implementer's are likely to make?

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | "The only thing we have to   | Periwinkle
(408)356-8506      | fear is fear itself." - FDR  | 16345 Englewood Ave
www.pwpconsult.com | Inaugural address, 3/4/1933  | Los Gatos, CA 95032

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Dec 2016 19:53:10 +0000

> If you didn't read enough, is this a mistake that implementer's are likely to make?

Not sure tbh - I've not given the draft a full read-through
for ages so it could well just be me. But I will give it a
full read as part of my AD review once the WGLC is done and
will watch out for this.

Cheers,
S.

---

From: Scott Schmit <[email-masked]>
Date: Sat, 31 Dec 2016 10:29:19 -0500

> folks.  It will *NOT* improve the security by one iota.

If we add an alert to be sent in this case, it would be possible for the
server to know why the clients were disconnecting and resolve the issue.

-- 
Scott Schmit

---

From: Adam Langley <[email-masked]>
Date: Sat, 31 Dec 2016 10:36:12 -0800

(Note: I'm reordering Brian's paragraphs here so that I can address
all of those on a single topic at a time.)

> limit should be longer, perhaps even hours.

In practice, at the moment, sites are generally using RSA
certificates, so a small device getting slashdotted would be dominated
by the RSA signing costs rather than the ECDHE.

But let's posit EdDSA certificates, where ECDHE generation might then
account for a 1/3 of the handshake cost. You make a good point that we
don't want to push low-end devices into PSK. Also, small devices are
less likely to be able to afford the tables that make fixed-base
operations fast.

I don't actually object to allowing servers to cache a ECDHE public
value for a small about of time. (QUIC currently does so for 30
seconds.) But I was worried about the arguments over the duration if I
specified one :)

Consider the motivations here:

1) We know that some implementations have gotten this wrong with TLS
1.2 and cached values for far too long. Presumably if they were to be
naively extended to TLS 1.3 this issue would carry over.

2) We probably disagree with this banking industry desire to be able
to backdoor their TLS connections, but we're not the police and fixing
DH values is probably how they would do it. If it's going to be A
Thing then it's much more likely that things will get misconfigured
and it'll be enabled in places where it shouldn't be. If we have no
detection mechanism then what we'll probably end up with is a Blackhat
talk in a few years time about how x% of banks botched forward
security at their frontends.

Say that a value of an hour makes sense for some device and we feel
that an hour's forward-security window is reasonable for security. The
issue is that it significantly diminishes our detection ability
because clients need to remember more than an hour's worth of values
and I don't know if we can dedicate that amount of storage to this.

Since I think the utility of this falls off as a reciprocal, I'll try
making a concrete suggestion for a time limit: 10 seconds.

> means that web browser connections to them are likely using the same

Thanks for pointing that out. I thought that saying "14.4%" and so on
was reasonable because it's a prevalence and we can assume that if
other sites did enable (EC)DHE then they would probably make the same
mistakes at a similar rate. But then I subtracted it from 100 and that
really doesn't make sense.

> latter intentional badness.

I much prefer people who are going to backdoor their TLS to use DH as
the mechanism rather than something less detectable. I don't expect a
MUST NOT will slow them down at all. I just want to ensure that this
doesn't accidently carry into 1.3, and that any unofficial backdoor
mechanism needed by some organisations doesn't inadvertently get
enabled more widely than planned.

Cheers

AGL