Re: [TLS] Safe ECC usage

Bill Frantz <> Sat, 19 October 2013 07:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEE9F11E8170 for <>; Sat, 19 Oct 2013 00:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y+EydLdvBKn3 for <>; Sat, 19 Oct 2013 00:01:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8B5BB11E8164 for <>; Sat, 19 Oct 2013 00:01:59 -0700 (PDT)
Received: from [] (helo=Williams-MacBook-Pro.local) by with esmtpa (Exim 4.67) (envelope-from <>) id 1VXQXr-0005P6-TB; Sat, 19 Oct 2013 03:01:56 -0400
Date: Sat, 19 Oct 2013 00:01:55 -0700
From: Bill Frantz <>
To: Nico Williams <>
X-Priority: 3
In-Reply-To: <>
Message-ID: <r422Ps-1075i-A727A9820DBE49F2997498DA5867FC55@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec791b834a56d7a00047ec2732b351683983350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Subject: Re: [TLS] Safe ECC usage
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 19 Oct 2013 07:02:05 -0000

On 10/18/13 at 9:00 AM, (Nico Williams) wrote:

>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

One possible solution is to use more than one algorithm. Having 
two signatures, both of which must validate, is robust even if 
one algorithm is compromised. Using two DH key agreements and 
XORing the results protects against one of them be compromised. etc.

This approach has costs. Some applications may be willing to pay 
them and others not. But TLS has a lot of options and users can choose.

Cheers - Bill

Bill Frantz        | Re: Hardware Management Modes: | Periwinkle
(408)356-8506      | If there's a mode, there's a   | 16345 
Englewood Ave | failure mode. - Jerry Leichter | Los Gatos, 
CA 95032