Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

From: Hugo Krawczyk <[email-masked]>
Date: Sun, 1 Jan 2017 12:43:06 -0500

There is more than one way to "backdoor" the use of DH (i.e., to not
enforce forward secrecy) and some of these ways are completely undetectable
(in particular, they would not repeat DH values). One has to be careful not
to give a false sense of security by the illusion that not detecting DH
repetition guarantees forward secrecy (FS). The value of a MUST NOT that
cannot be enforced is debatable even though it may serve as a strong
message to implementers that FS is an important property to comply with
(which is the domain of SHOULD). Another consideration is that there are
applications where FS is of little value, e.g. anything where the
requirement is authentication and not secrecy or where the secrecy
requirement itself is ephemeral.

Just to make it clear: I have been a supporter and promoter of forward
secrecy since the early days of IPsec and I think it is the most important
new feature of TLS 1.3, so the above should be understood as lukewarm
feelings towards FS. Just that we have to understand that we cannot have an
"anti-backdoor" guarantee and that there may be applications with
legitimate reasons not to use FS.

On Sat, Dec 31, 2016 at 1:36 PM, Adam Langley <[email-masked]>
wrote:

> (Note: I'm reordering Brian's paragraphs here so that I can address
> all of those on a single topic at a time.)
>
> On Thu, Dec 29, 2016 at 4:29 PM, Brian Smith <[email-masked]> wrote:
> > 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.
> >
> > 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.
>
> 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.
>
> >> 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.
> >
> > 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.
>
> 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.
>
> > Also, the Alexa top 1M isn't representative of every use of TLS, but
> > rather only one kind of application.
> >
> >> 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.
> >
> > 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.
>
> 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
>
> --
> Adam Langley [email-masked] https://www.imperialviolet.org
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Dan Brown <[email-masked]>
Date: Sun, 1 Jan 2017 19:25:29 +0000

There is more than 1 reason not to re-use ephemerals: forward secrecy (recent discussion), better resistance to side channels and fault attacks (e.g., invalid curves), and (informally?) less theoretical reliance of the strong/static Diffie-Hellman problems.

Re-use should be disallowed, though I agree run-time detection of a peer's re-use does not solve much.

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Hugo Krawczyk
Sent: Sunday, January 1, 2017 12:43 PM
To: Adam Langley
Cc: [email-masked]
Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

There is more than one way to "backdoor" the use of DH (i.e., to not enforce forward secrecy) and some of these ways are completely undetectable (in particular, they would not repeat DH values). One has to be careful not to give a false sense of security by the illusion that not detecting DH repetition guarantees forward secrecy (FS). The value of a MUST NOT that cannot be enforced is debatable even though it may serve as a strong message to implementers that FS is an important property to comply with (which is the domain of SHOULD). Another consideration is that there are applications where FS is of little value, e.g. anything where the requirement is authentication and not secrecy or where the secrecy requirement itself is ephemeral.

Just to make it clear: I have been a supporter and promoter of forward secrecy since the early days of IPsec and I think it is the most important new feature of TLS 1.3, so the above should be understood as lukewarm feelings towards FS. Just that we have to understand that we cannot have an "anti-backdoor" guarantee and that there may be applications with legitimate reasons not to use FS.

On Sat, Dec 31, 2016 at 1:36 PM, Adam Langley <[email-masked]<mailto:[email-masked]>> wrote:
(Note: I'm reordering Brian's paragraphs here so that I can address
all of those on a single topic at a time.)

Cheers

AGL

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

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 2 Jan 2017 00:29:28 +0200

> requirement itself is ephemeral.

My understanding of this matter is that this proposal isn't so much
about forcing FS, but ensuring that servers don't _accidentially_
screw up FS, as many TLS 1.2 servers do, even when using ECDHE cipher-
suites.

Those servers cache ECDH keys and apparently have no facily to roll
over ECDH keys as those use the same ones weeks or months over.

If such ECDH key gets compromised on still-live server, you don't
just get attacks where past connections have confidentiality 
compromised, but also attacks where _future_ connections have
confidentialty and _integerity_ compromised.

Yes, you can undetectalby undermine FS (and concrete methods of
doing that have been proposed in discussions within this WG), but
implementing that is nontrivial work, compared to just generating
ECDH key on startup and reusing it for lifetime of the process.

Also, when considering confidentiality, there is not just cofidentiality
of information itself, but also confidentiality of access of
information. I have seen lots of arguments against encryption that
completely ignore that.

-Ilari

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 2 Jan 2017 04:09:02 +0000

Hugo Krawczyk <[email-masked]> writes:

>there may be applications with legitimate reasons not to use FS. 

It's not so much reasons not to use FS (well, there are some specialised cases
where people want to do that as well), it's reasons to reuse (EC)DH values.
This isn't something that was ever mentioned in the spec, it's what developers
have implemented themselves in order to deal with high-load conditions.  This
also means that no matter what the spec might say in the future, if you've got
a developer facing a situation where they need 480% of available CPU to
service requests then they're going to do things like cache (EC)DH, regardless
of what the spec says.  So making it a MUST NOT will end up as what someone on
PKIX once described as "workgroup posturing".  Better to include an advisory
note on using it, for example what TLS-LTS says:

   TLS-LTS mandates the use of cipher suites that provide so-called
   Perfect Forward Secrecy (PFS), in which an attacker can't record
   sessions and decrypt them at a later date.  The PFS property is
   however impacted by the TLS session cache and session tickets, which
   allow an attacker to decrypt old sessions.  The session cache is
   relatively short-term and only allows decryption while a session is
   held in the cache, but the use of long-term keys in combination with
   session tickets means that an attacker can decrypt any session used
   with that key, defeating PFS:

   o  Implementations SHOULD consider the impact of using session caches
      and session tickets on PFS.  Security issues in this area can be
      mitigated by using short session cache expiry times, and avoiding
      session tickets or changing the key used to encrypt them
      periodically.

   Another form of cacheing that can affect security is the reuse of the
   supposedly-ephemeral DH value y = g^x mod p or its elliptic curve
   equivalent. Instead of computing a fresh value for each session, some
   servers for performance reasons compute the y value once and then reuse it
   across multiple TLS sessions.  If this is done then an attacker can compute
   the discrete log value from one TLS session and reuse it to attack later
   sessions:

   o  Implementations SHOULD consider the impact of reusing the y = g^x
      mod p value across multiple TLS sessions, and avoid this reuse if
      possible.  Where the reuse of y is unavoidable, it SHOULD be
      refreshed as often as is feasible.  One way to do this is to
      compute it as a background task so that a fresh value is available
      when required.

Peter.

---

From: Hugo Krawczyk <[email-masked]>
Date: Sun, 1 Jan 2017 23:59:11 -0500

Typo correction below.

On Jan 1, 2017 12:43 PM, "Hugo Krawczyk" <[email-masked]> wrote:

feelings towards FS

I guess it is clear from the context but the above sentence misses a NOT:
"The above should NOT be understood as..."

. Just that we have to understand that we cannot have an "anti-backdoor"
guarantee and that there may be applications with legitimate reasons not to
use FS.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Jan 2017 18:58:36 +0200

> making a concrete suggestion for a time limit: 10 seconds.

I like this number, because that’s the number I chose when I implemented ECDH caching in Check Point’s TLS library. It makes key generation rare enough that it makes no difference for server load in any normal hardware, and frequent enough that if you destroy the keys after they are last used then attackers have a very narrow window of opportunity to get your keys. Especially if they need to get a warrant. IoT may be abnormal hardware in that regard.

Still, if we want to accommodate the banking industry (or whatever part of it we’ve talked to in Seoul), then they need to be able to tell based on a timestamp which private key was used for that handshake. With 60 seconds key changes are rare enough that there are at most two possibilities which I think is manageable. With 10 seconds clock skew can ruin your system.  But I realize I’m bike shedding here.

On 2 Jan 2017, at 6:09, Peter Gutmann <[email-masked]> wrote:

> note on using it,

Well, it just so happens…
https://github.com/tlswg/tls13-spec/pull/768/files <https://github.com/tlswg/tls13-spec/pull/768/files>

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jan 2017 09:12:07 -0800

Yoav,

Thanks for pointing to this PR. Clearly we're only going to land one of
these.

One thing I wanted to note, as discussed in the comments on that PR, is
that at
least some of the proofs of security of TLS 1.3 assume that both sides use
fresh DH shares. In TLS 1.3, of course, the nonces provide freshness [0], so
intuitively reuse of DH shares should only threaten FS, however, an claims
that
that's actually the case should come with some analytic support. If reuse is
forbidden than no such support is needed.

-Ekr

[0] See SIGMA page 24 for a bit more on this topic.

On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir <[email-masked]> wrote:

> I like this number, because that’s the number I chose when I implemented
> ECDH caching in Check Point’s TLS library. It makes key generation rare
> enough that it makes no difference for server load in any normal hardware,
> and frequent enough that if you destroy the keys after they are last used
> then attackers have a very narrow window of opportunity to get your keys.
> Especially if they need to get a warrant. IoT may be abnormal hardware in
> that regard.
>
> Still, if we want to accommodate the banking industry (or whatever part of
> it we’ve talked to in Seoul), then they need to be able to tell based on a
> timestamp which private key was used for that handshake. With 60 seconds
> key changes are rare enough that there are at most two possibilities which
> I think is manageable. With 10 seconds clock skew can ruin your system.
> But I realize I’m bike shedding here.
>
> https://github.com/tlswg/tls13-spec/pull/768/files
>
> Yoav
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 2 Jan 2017 20:52:06 +0200

On Mon, Jan 02, 2017 at 06:58:36PM +0200, Yoav Nir wrote:
> 
> Still, if we want to accommodate the banking industry (or whatever
> part of it we’ve talked to in Seoul), then they need to be able to
> tell based on a timestamp which private key was used for that handshake.
> With 60 seconds key changes are rare enough that there are at most two
> possibilities which I think is manageable. With 10 seconds clock skew
> can ruin your system.  But I realize I’m bike shedding here.

- If this is actually banking, they AFAIK do have accurate enough
  clocks (sub-second).
- One can do seeded generation from ServerRandom. Adds load from use-
  once key generation, but avoids all time-skew problems.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jan 2017 10:59:45 -0800

Yoav,

Why do you need a precise clock here? If you're going to retrospectively
decrypt, you
are going to need a list of all the private keys, so why can't you just
index that by the
public key in the handshake?

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Jan 2017 21:43:41 +0200

> On 2 Jan 2017, at 20:59, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> .
>> 
> Why do you need a precise clock here? If you're going to retrospectively decrypt, you
> are going to need a list of all the private keys, so why can't you just index that by the

I’m assuming that the server generates private keys and saves them to a file along with the time period that they were used, and another machine in a different part of the network records traffic. It’s not so much that the clocks need to be accurate, as that they need to be synchronized, and there will still be some misalignment because of (variable) latency. 

I guess we are making guesses about systems that haven’t been written yet.

Yoav

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 2 Jan 2017 12:05:37 -0800

On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir <[email-masked]> wrote:

> I’m assuming that the server generates private keys and saves them to a
> file along with the time period that they were used, and another machine in
> a different part of the network records traffic. It’s not so much that the
> clocks need to be accurate, as that they need to be synchronized, and there
> will still be some misalignment because of (variable) latency.
>

Logging the actual session keys is a feature that some Enterprise
appliances have today, and that would continue to work in all scenarios
(sadly). It's not that much data to log (far less than a request log for
example). In that case it's often left unindexed and simple tools like grep
are used for ad-hoc decryption requests,which are typically rare enough not
to merit anything better.

For simplicities sake, I'd prefer single-use ECDHE, rather than
time-delimited. Mostly because it's simpler to implement. The current
generation of IOT and other small embedded systems are already at the point
where they can do this kind of thing.

-- 
Colm

---

From: Adam Langley <[email-masked]>
Date: Mon, 2 Jan 2017 12:57:05 -0800

On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir <[email-masked]> wrote:
> I’m assuming that the server generates private keys and saves them to a file
> along with the time period that they were used, and another machine in a
> different part of the network records traffic. It’s not so much that the

Addressing a few messages in one:

I didn't intend that this MUST NOT just be a "MUST NOT (but we know
you will)". I agree they're pretty useless. Rather I want this to be
checked in some clients and in tools like SSLLabs. I have some faith
that such measures will work to push an ecosystem towards correctness.

I don't expect that those who want to intercept TLS connections will
see a MUST NOT and go do something else. Rather I think they should
understand that TLS isn't supposed to be intercepted and, if they want
to do that, then they're going to be breaking the spec in places. I
think they're going to do that no matter what we do so I want to
ensure that these "interceptable" implementations don't inadvertently
proliferate. (Because if everything Just Works when you accidentally
copy such a config to your frontend server, then it'll happen.)

Cheers

AGL

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Jan 2017 18:14:23 -0600

On 12/30/2016 06:44 AM, Ilari Liusvaara wrote:
> On Thu, Dec 29, 2016 at 02:45:53PM -0800, Adam Langley wrote:
>>
>> 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.
> Sounds like standard-issue default-vhost attack (which are sadly
> common security issues in https://).
>  

Somehow, I feel like adding text in the 1.3 spec that servers should not
do this is not really going to help anyone.

>> 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.
> You mean redirecting full handshake meant for s1.example.com to
> s2.example.com? Or redirecting a TLS 1.2 resumption handshake?

Naively, if s1 and s2 share cert and private key, and ignore the SNI, it
seems like redirecting a full handshake would work.  But I didn't think
about it very hard.

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

Me, too.

-Ben

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 4 Jan 2017 06:29:01 +0200

> do this is not really going to help anyone.

I think it is much more HTTP-layer issue than TLS issue. After all, the
authoritative vhost info is available on HTTP layer. The TLS layer info
is not authoritative, especially in HTTP/2.

The last point is especially as coalescing information in HTTP/2 can
not be considered authenticatied (so attacker can trigger coalescing).

> seems like redirecting a full handshake would work.  But I didn't think

Actually, I think it would work if you merely have cross-valid 
selected certs. No need to share private key or even ignore SNI.

I'm aware of at least one TLS library that under no circumstances
ignores SNI for certificate selection (SNI with no known certificate
is always fatal error, and the returned certificate is always valid for
the name in SNI), but still can have redirect full handshakes if both
sides merely have a certificate that is valid for the other (no need
to share a key).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Jan 2017 15:38:23 +1100

> selected certs. No need to share private key or even ignore SNI.

That's almost ignoring SNI.  You are X but will accept a connection
for Y.  It's certainly true that you don't need to share keys, you
share valid credentials and are willing to use them.

Either way, your point is well made.  How servers identify themselves
is bound up in how they expect to be identified, which is often
ambiguous intentionally.

For example, it's common to have a single deployment configuration
across an entire cluster and to rely on SNI alone for picking a
certificate.  That way you simplify management and don't have to look
at IP addresses or anything like that.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Jan 2017 15:48:25 -0600

> at IP addresses or anything like that.

It seems like we're violently agreeing with each other, here, and should
settle on text to go (or not go) into the security considerations
section.  In the interest of sparking discussion, I propose the strawman:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

When a server has valid credentials for multiple server names, and at
least one of those names could also be served by valid credentials on a
different server, it may be possible for an attacker
to replay traffic from a client intended for the second server against
the first server, including 0-RTT data.  This behavior can be avoided if
the server knows what server name is expected for a given request (e.g.,
via an HTTP Host header) and verifies that the supplied SNI extension
matches the expected server name, though in some cases the mismatch is
harmless.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Though, to be honest, I'm not even 100% convinced that we need to add
new text.

-Ben

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 5 Jan 2017 10:05:18 +0200

> On 01/03/2017 10:38 PM, Martin Thomson wrote:

Checking that Host/:authority and SNI match does not work properly for
HTTP/2.

There, if you want to avoid default-vhost attacks, you have to check
:authority (Host) without reference to SNI.

-Ilari

---

From: Adam Langley <[email-masked]>
Date: Mon, 9 Jan 2017 14:55:57 -0500

> copy such a config to your frontend server, then it'll happen.)

I had understood that the desire from some large institutions to
intercept TLS connections arose only in a datacenter setting. However,
based on private conversations, it appears that at-least one of those
institutions does this on their public frontends and will very likely
do something worse than persistent ECDHE if that's not possible with
TLS 1.3.

Thus the hope that we can detect and reject this configuration by
default, and thus prevent unintended loss of forward security, without
pushing people into implementing interception in a way that's even
worse, appears to be gone.

So I'm disappointingly now thinking that we should simply say that DH
values "SHOULD NOT" be cached for more than 10 seconds. Something like
SSLLabs can still warn when that's violated, but clients probably
cannot enforce it without perverse consequences.

Cheers

AGL

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 10 Jan 2017 00:23:05 +0100

> do something worse than persistent ECDHE if that's not possible with

Why can't they just decrypt it, possibly encrypt it with some
other key, and store that?

Kurt