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

[Adam Langley <[e-mail]>]

(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 <[e-mail]> 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 [e-mail] https://www.imperialviolet.org