Re: [TLS] Safe ECC usage
Nico Williams <nico@cryptonector.com> Fri, 18 October 2013 16:01 UTC
Return-Path: <nico@cryptonector.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 2DD0811E8232 for <tls@ietfa.amsl.com>; Fri, 18 Oct 2013 09:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfOx3HnKAI+5 for <tls@ietfa.amsl.com>; Fri, 18 Oct 2013 09:01:28 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id AEDDA11E8263 for <tls@ietf.org>; Fri, 18 Oct 2013 09:01:16 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 1F1B4674091 for <tls@ietf.org>; Fri, 18 Oct 2013 09:01:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=1k9JR9TGmQIVMjWbG6gi 4dCVQxA=; b=NePvPNELmmiRcREntLh0l8Uc31YT9fv7lKD4M0zCC+esaLCwahss ufMOsvfQqmkoZjtGEIeqwzRblTR+8FQJCTpqPyT/TuoQnoPMg1MxBCeBoPhBR62r GdRI/t5e1K3KJjRYmXl1GGIFGutTFHvVPxOYIdSpJyv1kXINgAfhiVQ=
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id E0DF76740A9 for <tls@ietf.org>; Fri, 18 Oct 2013 09:00:19 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id f12so3964653wgh.19 for <tls@ietf.org>; Fri, 18 Oct 2013 09:00:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8zwpPJcT/EojP6IKV+un+etn3BDl1nZEV7TKCCe9sBw=; b=aqYfqzL8uU0qul3nCR1Q9RD+hRFbFs37eajdDUtcBkQ8wZCOJF/GhpqxZ7Lp9mypVP xkA4LfBhGcMlE85kxkubcZFcm5SGxaiS9LQr3DCLmwNB2JehfavvuT2lm2GcadF5+iIv 7Qe7+6F8n+6RN53QqI7hvZI7Sm6udQ6uKlbjnM+oHu6FYK0paw6dEv6f/o69DfXHANaP 3XbTMTfSN5IOMbIcM3VFbLr3T3K9/z7Y1NRW9i4Uckf5fFyMEfC1Y+IT93B8tLe4Fl3B OxXvbpUUZF9txMDUATgwSaZ93bNZc5NlR+eoYILt1f/uiilbp01jlpYSEZsVs8XWBO6r uehw==
MIME-Version: 1.0
X-Received: by 10.194.20.170 with SMTP id o10mr3276620wje.4.1382112017089; Fri, 18 Oct 2013 09:00:17 -0700 (PDT)
Received: by 10.216.151.136 with HTTP; Fri, 18 Oct 2013 09:00:16 -0700 (PDT)
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5BEDA76@XMB117CNC.rim.net>
References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> <CACsn0c=bSTMWwuHxD3eE3ABC_AxVRt-BOTybEr7umPQD5NB+cA@mail.gmail.com> <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> <CAK3OfOhH8xORP9YbGaf5Ly59oJGddeqi4-bZt5TZcQWP=WAqng@mail.gmail.com> <810C31990B57ED40B2062BA10D43FBF5BEDA76@XMB117CNC.rim.net>
Date: Fri, 18 Oct 2013 11:00:16 -0500
Message-ID: <CAK3OfOhmZSspUnZvae2BuHfKBuRM7GzQf9yd1VjFWYAHZ3eaXg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Dan Brown <dbrown@certicom.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "djb@cr.yp.to" <djb@cr.yp.to>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 18 Oct 2013 16:01:39 -0000
On Fri, Oct 18, 2013 at 9:21 AM, Dan Brown <dbrown@certicom.com> wrote: > Nico Williams wrote: >> Dan Brown wrote: >> > Why couldn't a new attack just work on one curve, namely Curve25519? >> > If I understand correctly, DJB has argued that the ECC theory and >> > experience would be evidence for a claim similar, but perhaps not as >> strong, as your claim. >> >> Let's say that there are single-curve attacks. We don't know how many >> curves have such attacks, nor how hard it is to find such attacks for >> specific curves, or specific curves with such attacks. Perhaps DJB >> does know, but either he got spectacularly lucky (if such attack/curve > > Well, you've assumed here, just like others, that attacks are random. If you > assume that attacks are random, then you are right that manipulation is the > main threat. I assumed all of: random attacks ("[w]ed don't know how many") and attacks where one knows how to create a curve so it will be vulnerable ("[w]e don't know ... how hard it is to find ... specific curves with such attacks"). > I've argued a few times that assuming random attacks is too optimistic, and > also close to circular reasoning, and not supported by the evidence. Random attacks are the reason to want rigid curve selection processes. That leaves the other possibility, that the curve author knows how to create curves that will be vulnerable to some class of attacks without a random search. Here we can use curve selection criteria that involve parameter selections that no one person/entity can control -- verifiably. Surely that was your point, no? That curve25519 might be "special" (as in specially weak) in some way that you (and I) don't know. > Remember, Curve25519, though free from the potential of malicious > manipulation, is chosen, in part, for its special efficiency properties. > > These special properties may also given an attacker special advantages. DJB > has already argued, based on the existing attacks -- not random attacks -- > that this is unlikely. And I agreed. > > Consider the ECC history. After resisting all generic attacks, we have the > following > > Miyaji proposed special trace 1 curves. A few years later, these were broken > by the SASS attack. > > Various proposed supersingular curves. Later, they were broken by the MOVFR > attacks. > > But ever since then, it has been fairly quiet on the prime-field side of ECC. We can look at things other than the constants in curve25519 (and curve 1174, and curve3617) -- the class(es) of curve(s) that it (they) fits.. separately from the curve selection criteria. How do we mitigate unknown weaknesses in each curve class? The only thing I know is: algorithm agility. As for selection criteria, I think I'd prefer a verifiably random selection process over the smallest freedom approach, but where there's doubt about the random selection process' verifiability I prefer the latter over the former. The problem is that as time passes it becomes more difficult to verify that a long-ago random selection process was not manipulated -- we have to trust records of history in order to believe that it wasn't. >> pairs are rare) or such attack/curve pairs are very common. The latter >> would imply that all ECC is busted, in which case we needn't worry >> about whether Curve25519 is weak because we have bigger problems, so we >> must ignore this possibility when comparing curves to one another. > > Furthermore, if we admit this possibility, i.e. to justify that the ECDLP over > P256, then we should not just ignore it, but consider alternatives to ECC. I didn't mean that we should flat out ignore that possibility. I was very specific: "... so we must ignore this possibility WHEN COMPARING CURVES TO ONE ANOTHER". I said nothing about comparing ECC to non-ECC. Once more, the only way I know of to mitigate against unknown attacks is algorithm agility. For ephemeral DH algorithm agility is relatively simple: require to implement N different DH algorithms, make it easy to turn off any of them if they get broken. For other ECC uses algorithm agility is much harder: it involves re-keying. We could require that principals have N public keys (in PKI cases, that all N certs have the same names and so on, issued by the same issuer), so that it's possible to drop any one that gets broken later. But even this, I think, may be too much to ask for. So at some point we have to pick something. At some point, in spite of uncertainty, we have to select some algorithm as the one we're going to rely on the most for authentication. Which would you rather use? >> That leaves the former, and now we need some estimate of frequency of >> such attack/curve pairs in order to decide if any one curve is weak. > > Of course, it's very hard to make such estimates. Even so, there is merit in > making such estimates. They have to been based on evidence. There two types > of evidence here: > > 1. The lack of new attacks, despite efforts and incentives. > > 2. The existing attacks, e.g. MOVFR and SASS. > > Intuition might entirely dismiss inferring estimates from this evidence set, > as wild speculation. More formally, intuition would be saying the inference > drawn from the set have low confidence. So do nothing? Ignore the whole field? I'm not sure where you're going with this. What specific advice are you giving us? Nico --
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Stephen Farrell
- [TLS] draft-sheffer-tls-bcp: DH recommendations Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael D'Errico
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Xuelei Fan
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael Ströder
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael Ströder
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael Ströder
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Bill Frantz
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Ralph Holz
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael Ströder
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael Ströder
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael D'Errico
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Stephen Farrell
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael D'Errico
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Ralph Holz
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Ralph Holz
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Nikos Mavrogiannopoulos
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Alex Elsayed
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael D'Errico
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Kyle Hamilton
- Re: [TLS] Safe ECC usage Johannes Merkle
- Re: [TLS] Safe ECC usage Adam Langley
- Re: [TLS] Safe ECC usage Santosh Chokhani
- Re: [TLS] Safe ECC usage Martin Rex
- Re: [TLS] Safe ECC usage Kyle Hamilton
- Re: [TLS] Safe ECC usage Yoav Nir
- Re: [TLS] Safe ECC usage Martin Rex
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Johannes Merkle
- Re: [TLS] Safe ECC usage Manuel Pégourié-Gonnard
- Re: [TLS] Safe ECC usage Yoav Nir
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Johannes Merkle
- [TLS] (offline note) Re: Safe ECC usage Rene Struik
- Re: [TLS] Safe ECC usage D. J. Bernstein
- [TLS] (EC)DSA potential problems (ECC "brittlenes… Martin Rex
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Watson Ladd
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Johannes Merkle
- Re: [TLS] Safe ECC usage Nico Williams
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Nico Williams
- Re: [TLS] Safe ECC usage Michael StJohns
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Nico Williams
- Re: [TLS] Safe ECC usage Bill Frantz
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- [TLS] DH group negotiation extension [was: Re: dr… Daniel Kahn Gillmor
- Re: [TLS] DH group negotiation extension [was: Re… Dang, Quynh
- Re: [TLS] DH group negotiation extension [was: Re… Patrick Pelletier
- Re: [TLS] DH group negotiation extension [was: Re… Watson Ladd