Re: [stir] Choice of STIR signature algorithm

[Richard Shockey <[e-mail]>]

On 4/7/16, 8:04 AM, "Chris Wendt" <[e-mail]> wrote:

>Hi Richard,
>
>I’m not sure that is the right perspective to look at this.
>
>EC has good properties, especially when it comes to CPU, but also from it’s cryptographic strength.  I care a lot about the CPU part, from a cost point of view, so i think that is number 1 priority.

ca
RS> Of course there is no argument about that. In a US/CA NANP carrier implementation environment I would assume its mandated. If you started to look at how a NANP STIR RFP would be constructed you would put severe constraints on options. And on costs.. Well no one, certainly not your employer,  is going to pay 500M a year for this or even 140M if you know what I mean. :-) 



>
>But, RSA256 is there today as most commonly used, so it’s hard to not include.


RS> MUST support but do not mandate implementation. We’ll deal with that when we start to look at the national specific deployment options. Chris what I want to see is a protocol and nothing else. Please insert implementable examples in the drafts. Where do you see this in the INVITE with actually examples.  I will raise hell if I don’t see this in the future. Jon’s draft is rhetoric and nothing else it is non implementable. 


>
>I think the consensus was that RSA256 comes mostly free in many of the likely implementations out there.
>
>I would argue EC does as well, but i’ll give the benefit of the doubt to say, not everyone is completely comfortable with it or may need some more time to have a production grade implementation perhaps.

RS> I still think the TLS issue in SIPConnect is applicable. The IETF can bark all it wants but in the end if the industry will not support it will not deploy and there is way too much ideology and political correctness in the way some protocols are developed.


>
>We do need to recognize that as time goes on, the best practice will change so the number of algorithms will follow a similar path that the TLS world is dealing with, so this isn’t the end of the story either.


RS> Agreed but STIR with your new concepts has a great chance of actually deploying. Do not burden it by defining constraints you know our industry will not accept. 


>
>Two MTI today, likely more tomorrow, or deprecated algorithms as well.
>
>This is reality, so let’s look at it more in that light.
>
>-Chris
>
>
>> On Apr 6, 2016, at 10:11 PM, Richard Shockey <[e-mail]> wrote:
>> 
>> 
>> 
>> Implement is one thing, must use in verification is another.  I won’t support MUST be able to verify. 
>> 
>> This is shaping up to be another TLS food fight re SIP PBX’s and the carriers re SIP Connect and we all know where that went. Nowhere. Must support use ..well maybe. 
>> 
>> 
>> — 
>> 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/6/16, 12:09 PM, "stir on behalf of Robert Sparks" <[e-mail] on behalf of [e-mail]> wrote:
>> 
>>> To be clear, the suggestion is must implement, not must use. 
>>> Specifically, for _this_ part of the conversation, its that the code in 
>>> a verifier must be _able_ to verify presented with either.
>>> 
>>> 
>>> On 4/5/16 7:47 PM, Richard Shockey wrote:
>>>> 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
>>>> _______________________________________________
>>>> 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
>