Re: [TLS] Safe ECC usage
Nico Williams <nico@cryptonector.com> Fri, 18 October 2013 20:28 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 D3D1811E81E8 for <tls@ietfa.amsl.com>; Fri, 18 Oct 2013 13:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.084
X-Spam-Level:
X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 58bwqyHC0G45 for <tls@ietfa.amsl.com>; Fri, 18 Oct 2013 13:28:20 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2AC11E8191 for <tls@ietf.org>; Fri, 18 Oct 2013 13:28:19 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id BF8ACB8058 for <tls@ietf.org>; Fri, 18 Oct 2013 13:28:18 -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=QQhrrCq2aBbUZ3q1MxCX OwC2Fds=; b=PkiPdUNYwGOO/FgmqZwedlqWgIlrxlFRYAoA/PQGGkL5huDpYaTK gQ3q412gY9J27yMtwl0ZTEXC+DWidWwpjV2HoCnGneO9k+n020Yss6eT1TBUudCA R7w2szO/31xFiPiRwxKbIcR63rdrhH2Z5WlY+tJTZRuljpW1ib/rnCM=
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 5065AB800A for <tls@ietf.org>; Fri, 18 Oct 2013 13:28:18 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id u57so4327706wes.29 for <tls@ietf.org>; Fri, 18 Oct 2013 13:28:16 -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=qS8crz5vVs1HJxRf8w3I/uzuQySp3MH1ICNK+ULYUzM=; b=XskK3tTdcTvrkfbhpqzHK0ChVrWop9YnvigoTXqiybjja3Ll16dWtFM/ebD4o+Kf1M /hLjOPA4ATkEIPnx7eyQkQ+TbXRCUlJhKK8bYU6ELyyLVW5Yd6InCAAbf6b8+/zG/NFb hwmilFNLseWx7lbEWwmvqrKlM8OMK1SR2oUHTD42xOJ2sIZEgKUnPaN/QG8/e3Tdhdk9 8QWnXn0bIquxl1Rr3h6dzit6FJFTnDbPr/Us9PELc3wiD4t7SuAMSZT8+/vs57diu2wA rZDwbQ3BdTtVNB4THLMxzLhGDZAkpt6EzfQ/yQjoQQQ8yOtr6em1xLhjECKE8OjBjCgJ uoag==
MIME-Version: 1.0
X-Received: by 10.194.81.135 with SMTP id a7mr3320147wjy.56.1382128096464; Fri, 18 Oct 2013 13:28:16 -0700 (PDT)
Received: by 10.216.151.136 with HTTP; Fri, 18 Oct 2013 13:28:16 -0700 (PDT)
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5BEDD49@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> <CAK3OfOhmZSspUnZvae2BuHfKBuRM7GzQf9yd1VjFWYAHZ3eaXg@mail.gmail.com> <810C31990B57ED40B2062BA10D43FBF5BEDD49@XMB117CNC.rim.net>
Date: Fri, 18 Oct 2013 15:28:16 -0500
Message-ID: <CAK3OfOixCH-+2o7Qd38FB6HOF4ab9h29g=e=iEsYbj9LVTeHSw@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 20:28:25 -0000
On Fri, Oct 18, 2013 at 1:42 PM, Dan Brown <dbrown@certicom.com> wrote: > Nico Williams wrote: >> Dan Brown <dbrown@certicom.com> wrote: >> > Nico Williams wrote: >> >> Random attacks are the reason to want rigid curve selection processes. > > Yes, good point and sentence. > > Special attacks are the reason to want random curve selection. But then you need to construct a random curve selection process that everyone will be able to believe [years later!] was not manipulated. That's very difficult. Even if we eliminate the unreasonably paranoid from "everyone". And then what if the selected curves don't perform well? Pick the next closest well-performing curve? How would such a procedure affect the trustworthiness of the selection process? At least with DJB's curves I only need to worry that DJB (et. al.) has knowledge about cryptanalysis on said curves that he (they) are not sharing, that DJB is mounting an attack on us. You worry about special attacks that are not known to the public nor DJB, but to me that's the same as "random", and all I care about is that the curve authors not have known about them a priori, because then we can reason (with no data, granted, so it's all hand waving) about the density of such attacks in the neighborhood of the curves in question. >> 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. > > In addition to algorithm agility, random curve selection mitigates unknown > weaknesses, e.g. Brainpool or P256 (but only if you trust its creator). But since Dual_EC, we don't trust P256's creators. That's a key reason for this entire discussion. > Hmm, maybe, I am missing your point about "curve class". s/class/family/. > I believe that, elsewhere in this thread, I said algorithm agility would be a > very good reason for including Curve25519, in addition to Brainpool. OK, good. > Algorithm agility, though, does not help much, in general, against untold > attacks (mainly helping against newly announced attacks). Unless you also have enough diversity of algorithms to begin with. That's why a number of algorithms would have to be required to implement (quite a few, actually, considering your doubts anyways, and assuming we can't get good consensus on just two; you might have doubts about just two different algorithms). > In particular, we don't want to TLS to become laissez-faire roll any algorithm > you want, i.e. the ultimate in algorithm agility? At some point, TLS > considers the evidence and picks a few good algorithms, right? The choice > governing this selection of each algorithm is not primarily algorithm agility. But it should be -- it should be about ability to survive cryptanalytic advances. We've experienced this w.r.t. chained IV CBC cipher modes in SSHv2, for example, where having deployed counter modes saved our collective bacon once. > For example, AES was chosen for inclusion in TLS, not because of algorithm > agility but because of the extensive analysis it underwent. TLS did not, and > still does not, adopt every single newly proposed algorithm in the name of > algorithm agility. So, something other than algorithm agility seems to be > protecting TLS. I understand this. And given the time we've had to cryptanalyze AES maybe we feel really good about it, so maybe we don't need so many symmetric ciphers. But your arguments, assuming they carry the day, argue for having several key exchange and signature algorithms -- I don't see how else to interpret what you're saying. > Also, separately from but similary to algorithm agility, algorithm X is not > usually adopted in TLS just on the grounds that we know of no attack, else > each new proposal would be adopted. So, it is inconsistent to consider only > about known attacks. TLS has to consider what evidence there is against > unknown attacks. There's only so much we can do about unknown attacks. Algorithm agility + lots of algorithms (each from a different family). > - random curves have slightly more assurance than special > - if the threat against P256 is serious, then we had better seriously consider > non-ECC You lost me with the second point. As to the first, the problem is that assurance for random selection is difficult -- aside from that I'd agree. > The evidence set for the two points is similar, which may cause me to look > like an arguing for one point, when I am trying to argue the other. > > Put another way, what's the point in comparing curves to each other, if we > believe there's a bigger problem of ECC being busted. Yes, we need non-ECC algorithms too, well, at least for as long as they are practical (i.e., RSA with 16KB keys are not). But anyways, we also need ECC because of its performance benefits. At least until quantum computers become sufficiently powerful that we have to drop this entire field of cryptography anyways. >> 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? > > Hmm, as an end user, I might go for the safest possible that can run on my > device. Well, OK, but we have a large diversity of devices and device capabilities. If we're going to wind down this thread with a conclusion, we should get more specific. > My own intuition: I think ECC is safe, and that in the very unlikely case of > any untold attacks, they will be at most similar in impact to MOVFR and SASS. OK, thanks. My own intuition is that DJB's curves are safe from as-yet unknown attacks. It's just intuition. > My advice: definitely don't worry about Brainpool. Don't worry about P256, > unless you view its creator as an adversary and you are somehow required to > use ECC, almost against your will, instead of some alternative like RSA or > integer DH. Consider Curve25519 mainly if you really want efficiency, or > don't trust the reliability of your implementation, and maybe also have dim > view on the security of ECC alternatives. DJB argues cogently that the NIST curves are not safe enough. I'm OK with Brainpool, but there are still significant advantages to DJB's curves. > TLS can safely adopt all these EC choices. > > At some point, though, TLS may not want to allow too many choices. Well, I think we're way past that point as to non-required to implement algorithms. The problem there is the cartesian product explosion of cipher suite IDs. As for required to implement algorithms, we're not. Nico --
- [TLS] draft-sheffer-tls-bcp: DH recommendations Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Stephen Farrell
- 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