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

Dan Brown <danibrown@blackberry.com> Sun, 01 January 2017 19:25 UTC

Return-Path: <danibrown@blackberry.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3DD1293F3 for <tls@ietfa.amsl.com>; Sun, 1 Jan 2017 11:25:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.7
X-Spam-Level:
X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G62ArHvXIyV5 for <tls@ietfa.amsl.com>; Sun, 1 Jan 2017 11:25:33 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD26126B6D for <tls@ietf.org>; Sun, 1 Jan 2017 11:25:32 -0800 (PST)
Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs215cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jan 2017 14:25:31 -0500
Received: from XCT116CNC.rim.net (10.65.161.216) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 1 Jan 2017 14:25:30 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Sun, 1 Jan 2017 14:25:29 -0500
From: Dan Brown <danibrown@blackberry.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>, Adam Langley <agl@imperialviolet.org>
Thread-Topic: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh
Thread-Index: AQHSZFacWjk79u0NfEqEhUFEOLMDMKEkAPK3
Date: Sun, 01 Jan 2017 19:25:29 +0000
Message-ID: <20170101192527.5705805.69243.8791@blackberry.com>
References: <CAMfhd9Urd1DWF9yhMdhvx1AcKyB4-E7Qy+tzqz_-1RpXR+Wp1w@mail.gmail.com> <CAFewVt44xm3rgm=n8PpEcqbTvC-Ei2EvoJciL=+m2UnQ-fUm2A@mail.gmail.com> <CAMfhd9Xq4RA6XBqLZtsbWSnMk4SnvZLC9V3_gCH-FzyVBMg4xg@mail.gmail.com>, <CADi0yUPSkBhyuX7utW1tsVkkbDc6YgBLie41qWPwbo+X6CpuZA@mail.gmail.com>
In-Reply-To: <CADi0yUPSkBhyuX7utW1tsVkkbDc6YgBLie41qWPwbo+X6CpuZA@mail.gmail.com>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_201701011925275705805692438791blackberrycom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GWeWBiWYV1RVi4QV2PHpKcL9XO0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Jan 2017 19:25:35 -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: tls@ietf.org
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 <agl@imperialviolet.org<mailto:agl@imperialviolet.org>> 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 <brian@briansmith.org<mailto:brian@briansmith.org>> 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 agl@imperialviolet.org<mailto:agl@imperialviolet.org> https://www.imperialviolet.org

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls