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
--