Re: [stir] Choice of STIR signature algorithm

Russ Housley <housley@vigilsec.com> Tue, 05 April 2016 21:55 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDE612D1F0 for <stir@ietfa.amsl.com>; Tue, 5 Apr 2016 14:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 ClGApNjYyUx4 for <stir@ietfa.amsl.com>; Tue, 5 Apr 2016 14:55:47 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8CF12D0CC for <stir@ietf.org>; Tue, 5 Apr 2016 14:55:47 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 6AA7EF24064 for <stir@ietf.org>; Tue, 5 Apr 2016 17:55:47 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id wmkfUFWjz17G for <stir@ietf.org>; Tue, 5 Apr 2016 17:41:16 -0400 (EDT)
Received: from dhcp-b4d9.meeting.ietf.org (dhcp-b4d9.meeting.ietf.org [31.133.180.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 10CD1F24035 for <stir@ietf.org>; Tue, 5 Apr 2016 17:55:45 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <A3723DBB-476C-4F22-95E0-37AE0872FBBD@shockey.us>
Date: Tue, 05 Apr 2016 17:55:43 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4F09888-780B-4725-9A74-AD2EF661C5C0@vigilsec.com>
References: <D32953D1.4770F%john.mattsson@ericsson.com> <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <D329995E.477D9%john.mattsson@ericsson.com> <A3723DBB-476C-4F22-95E0-37AE0872FBBD@shockey.us>
To: IETF STIR Mail List <stir@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stir/PHzYEx3pLXpc58Yd9YIegd2uVag>
Subject: Re: [stir] Choice of STIR signature algorithm
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2016 21:55:50 -0000

There was just a discussion of this point in the STIR session at IETF 95.  The sense of the room is to require verification of both RSA and ECC signatures.  This allows the use of existing infrastructure, and allows rapid movement to ECC as soon as that infrastructure is readily available

Russ


On Apr 5, 2016, at 4:46 PM, Richard Shockey <richard@shockey.us> wrote:

> 
> And on a nation state basis my assumption would be that something like ECC256 would be a requirement for the computational load factor if nothing else.
> 
> Its certainly how I would write a STIR RFP for a CA if this were for the carriers in the NANP. Setting one or two SHOULD supports seem sensible. I would not set the requirement to MUST. 
> 
> — 
> Richard Shockey
> Shockey Consulting LLC
> Chairman of the Board SIP Forum
> www.shockey.us
> www.sipforum.org
> richard<at>shockey.us
> Skype-Linkedin-Facebook rshockey101
> PSTN +1 703-593-2683
> 
> 
> 
> 
> 
> 
> 
> 
> On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" <stir-bounces@ietf.org on behalf of john.mattsson@ericsson.com> wrote:
> 
>> I think that this has changed, and will change even more until STIR is
>> deployed. According to notary.icsi.berkeley.edu/#statistics 23 % of all
>> TLS connections are currently setup with ECDSA certificates. One example
>> is https://en.wikipedia.org. And we don’t need unanimous support from all
>> CAs; it is enough that ECDSA certificates are fairly easy to get.
>> 
>> (Ed25519 certificates are probably hard to get unless you run your own CA).
>> 
>> 
>> John
>> 
>> On 05/04/16 15:07, "Peterson, Jon" <jon.peterson@neustar.biz> wrote:
>> 
>>> To date we have not moved this to EC because (at least as far as I
>>> understand things) many elements of web PKI, including many CAs, don't
>>> support these algorithms yet. If our assessment of that is changing, then
>>> let's revisit it. 
>>> 
>>> Jon Peterson
>>> Neustar, Inc. 
>>> 
>>> Sent from my iPad
>>> 
>>>> On Apr 5, 2016, at 11:37 AM, John Mattsson <john.mattsson@ericsson.com>
>>>> wrote:
>>>> 
>>>> I think there are several strong reasons to change the default signature
>>>> algorithm in draft-ietf-stir-rfc4474bis and draft-ietf-stir-passport.
>>>> The
>>>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using SHA-256),
>>>> but
>>>> I cannot find any number for MTI/Recommended/Minimum/Default key length.
>>>> 
>>>> 1. RSA signing is extremely slow compared to modern alternatives. On a
>>>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times faster
>>>> than RSA-2048, and Ed25519 is 67 times faster
>>>> (https://bench.cr.yp.to/results-sign.html) As RSA-2048 is normally
>>>> classified as roughly 112-bit security (RFC3766, NIST, ENISA), a more
>>>> fair
>>>> comparison is with RSA-3072, and then ES256 is 52 times faster and
>>>> Ed25519
>>>> is 169 times faster.
>>>> 
>>>> 2. RSA signatures are much larger than their ECC counterparts. RSA-2048
>>>> signatures are 256 bytes and RSA-3072 signatures are 384 bytes, while
>>>> ES256 and Ed25519 signatures are only 64 bytes.
>>>> 
>>>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security proofs,
>>>> no
>>>> advantages, is disrecommended by ENISA (European Union Agency for
>>>> Network
>>>> and Information Security), and has been replaced in TLS 1.3. I do not
>>>> think this is the algorithm we should use in STIR.
>>>> 
>>>> I think the right algorithm choice for STIR is ES256 or Ed25519.
>>>> Signature processing is likely the main burden for the Authentication
>>>> Service, and changing from RSA to ECC significantly reduces the amount
>>>> of
>>>> hardware needed, and therefore the cost. A single 3.3 Ghz Skylake core
>>>> can
>>>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, but 21,000
>>>> ES256 or 68,000 Ed25519 signatures per second. RSA verification is a bit
>>>> faster than ECC, but the different is much smaller that for signing,
>>>> RSA-3072 verifications are e.g. twice as fast as Ed25519 verifications.
>>>> 
>>>> Cheers,
>>>> John
>>>> 
>>>> 
>>>> ------------------------------------------------------------------
>>>> JOHN MATTSSON
>>>> MSc Engineering Physics, MSc Business Administration and Economics
>>>> Ericsson IETF Security Coordinator
>>>> Senior Researcher, Security
>>>> 
>>>> _______________________________________________
>>>> stir mailing list
>>>> stir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/stir
>> 
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir