Re: [stir] Choice of STIR signature algorithm

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