Re: [stir] Choice of STIR signature algorithm

Eric Burger <eburger@standardstrack.com> Thu, 07 April 2016 09:43 UTC

Return-Path: <eburger@standardstrack.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 59ACF12D5E5 for <stir@ietfa.amsl.com>; Thu, 7 Apr 2016 02:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level:
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com
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 sLsYE_ZDQpMo for <stir@ietfa.amsl.com>; Thu, 7 Apr 2016 02:43:40 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928F612D606 for <stir@ietf.org>; Thu, 7 Apr 2016 02:43:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type; bh=JEk5zpYx5QoZ7lMryyhhkMfJXOsY7OaeSJa9E1lEQA0=; b=o70eEVMfLQQq3y8Ip7tczg4Nfl AtH8/FSYu45IWuj1FjdkAvD35kL6Xgly9GgZi91Uf7JO3Gx58qC5DJn8HpXvAdHCYvbdnC6rYdfJb 5hc8Im9uioBqychCr6h+3j6fra92IIxfBzagovPTp5fdhEZR3/mpnhN9+INHBzpEeUdM=;
Received: from [190.192.31.24] (port=53169 helo=[192.168.0.6]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <eburger@standardstrack.com>) id 1ao6TO-0008RV-Dr for stir@ietf.org; Thu, 07 Apr 2016 02:43:38 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_E9F3688D-A1F4-408F-A23D-C4FFA33125D3"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Pgp-Agent: GPGMail 2.6b2
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <D329995E.477D9%john.mattsson@ericsson.com>
Date: Thu, 07 Apr 2016 06:43:32 -0300
Message-Id: <6C45B889-0874-4C2A-891D-8ABFD3F0D2B2@standardstrack.com>
References: <D32953D1.4770F%john.mattsson@ericsson.com> <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <D329995E.477D9%john.mattsson@ericsson.com>
To: "stir@ietf.org" <stir@ietf.org>
X-Mailer: Apple Mail (2.3124)
X-OutGoing-Spam-Status: No, score=-2.1
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/stir/LHRurlHmxLADGd7QkS6VU4AZrfU>
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: Thu, 07 Apr 2016 09:43:42 -0000

The statement that using ECDSA at the single MTI would hold up STIR deployment is factually incorrect. It is not a changing view that CA’s do ECDSA. Major CA’s have been doing ECDSA for over a year.

Personally, going from RSA to ECDSA is a minor pain for me because my RSA code is running. However, I expect my ECDSA code to be running next week. Thus, I might have a selfish incentive to say, “Do RSA now and we will do ECDSA in phase never.” However, I would much rather have a well-implemented, useful, and scalable implementation than a weak, already obsolete, and resource intensive implementation.

If one is trying to slow down the adoption of STIR by saying we could not possibly use modern, scalable crypto, or trying to slow down the adoption of STIR by saying that we need a more complex protocol that is statistically more likely to have bugs, that is a losing argument IMHO. To quote someone from the room, I would not want to be the person standing in front of the FCC explaining why STIR is not up to IETF standards. I would rather be the person who is explaining why STIR is the appropriate solution for VoIP caller ID spoofing mitigation.

> On Apr 5, 2016, at 5:04 PM, John Mattsson <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