Re: [TLS] Safe ECC usage

Bill Frantz <frantz@pwpconsult.com> Sat, 19 October 2013 07:02 UTC

Return-Path: <frantz@pwpconsult.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 BEE9F11E8170 for <tls@ietfa.amsl.com>; Sat, 19 Oct 2013 00:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Y+EydLdvBKn3 for <tls@ietfa.amsl.com>; Sat, 19 Oct 2013 00:01:59 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5BB11E8164 for <tls@ietf.org>; Sat, 19 Oct 2013 00:01:59 -0700 (PDT)
Received: from [173.75.83.95] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1VXQXr-0005P6-TB; Sat, 19 Oct 2013 03:01:56 -0400
Date: Sat, 19 Oct 2013 00:01:55 -0700
From: Bill Frantz <frantz@pwpconsult.com>
To: Nico Williams <nico@cryptonector.com>
X-Priority: 3
In-Reply-To: <CAK3OfOhmZSspUnZvae2BuHfKBuRM7GzQf9yd1VjFWYAHZ3eaXg@mail.gmail.com>
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
X-Originating-IP: 173.75.83.95
Cc: djb@cr.yp.to, 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: Sat, 19 Oct 2013 07:02:05 -0000

On 10/18/13 at 9:00 AM, nico@cryptonector.com (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
>use?

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
www.pwpconsult.com | failure mode. - Jerry Leichter | Los Gatos, 
CA 95032