Re: [Cfrg] ECC reboot

Rob Stradling <rob.stradling@comodo.com> Mon, 20 October 2014 09:40 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618FE1A7026 for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 02:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.609
X-Spam-Level:
X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az7CV03WTU20 for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 02:40:52 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092FC1A7020 for <cfrg@irtf.org>; Mon, 20 Oct 2014 02:40:51 -0700 (PDT)
Received: (qmail 21219 invoked by uid 1000); 20 Oct 2014 09:40:47 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 20 Oct 2014 10:40:47 +0100
Message-ID: <5444D89F.5080407@comodo.com>
Date: Mon, 20 Oct 2014 10:40:47 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
References: <D065A817.30406%kenny.paterson@rhul.ac.uk><54400E9F.5020905@akr.io><CAMm+LwhVKBfcfrXUKmVXKsiAMRSTV+ws+u07grmxkfnR2oYJoQ@mail.gmail.com><5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org><m3r3y6z3z8.fsf@carbon.jhcloos.org> <CA+Vbu7x4Y_=JZ9Ydp=U5QnJokL28QMQnV4XUn9S6+CUZR9ozEw@mail.gmail.com>
In-Reply-To: <CA+Vbu7x4Y_=JZ9Ydp=U5QnJokL28QMQnV4XUn9S6+CUZR9ozEw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/H_RPRsqE2j2HI81__v39WGjGq60
Subject: Re: [Cfrg] ECC reboot
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Oct 2014 09:40:55 -0000

On 18/10/14 01:10, Benjamin Black wrote:
> On Fri, Oct 17, 2014 at 4:11 PM, James Cloos <cloos@jhcloos.com
> <mailto:cloos@jhcloos.com>> wrote:
>
>      >>>>> "MH" == Michael Hamburg <mike@shiftleft.org
>     <mailto:mike@shiftleft.org>> writes:
>
>     MH> I looked at Mozilla’s included CAs.  There are four ECC certs there,
>     MH> all of them on the NIST secp384r1 curve.  So they apparently do not
>     MH> consider ~512 bits necessary, but if the only choices are 256 and 512
>     MH> I suppose they will go with 512.

When we generated our ECC root CA keys in 2008, secp384r1 seemed like 
the best choice.  secp521r1 wasn't in Suite B, and it seemed likely that 
Suite B compliance would be a requirement for some of our customers.

BTW, I strongly suspect that secp521r1/SHA-512 certificate signatures 
are in practice unusable in WebPKI TLS.  RSA/SHA-512 certificate 
signatures are definitely unusable.  The problem isn't lack of support 
for any of the algorithms in the crypto libraries.  Rather, the problem 
is that TLS clients commonly don't specify RSA/SHA-512 and ECDSA/SHA-512 
in the TLS signature_algorithms extension.  Some servers respond by 
refusing to serve certs with SHA-512 signatures.

>     The nist 2^521-1 curve probably wasn't available in enough software.
>
>     Presumably for the same reason suite-B lost it.  (Which, AIUI, was some
>     ipr claim, yes?)
>
> Per an earlier thread, P521 was not intended to be in Suite B, but
> AES-192 was. Since AES-192 was not broadly implemented, P384 was paired
> with AES-256, instead.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online