Re: [stir] Choice of STIR signature algorithm

[Richard Shockey <[e-mail]>]

Well I would have to insist that such a statement is SHOULD verify, either or both, how it deploys and under what conditions are still probably a nation-state matter certainly if they are used with E.164 plan.


On 4/5/16, 5:55 PM, "stir on behalf of Russ Housley" <[e-mail] on behalf of [e-mail]> wrote:

>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 <[e-mail]> 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 [phone]
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" <[e-mail] on behalf of [e-mail]> 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" <[e-mail]> 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 <[e-mail]>
>>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/stir
>>> 
>>> _______________________________________________
>>> stir mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/stir
>> 
>> _______________________________________________
>> stir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stir
>
>_______________________________________________
>stir mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/stir