Re: [stir] Choice of STIR signature algorithm

Richard Shockey <richard@shockey.us> Tue, 12 April 2016 20:35 UTC

Return-Path: <richard@shockey.us>
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 871F812D8D9 for <stir@ietfa.amsl.com>; Tue, 12 Apr 2016 13:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us
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 aVEqj3_wakhK for <stir@ietfa.amsl.com>; Tue, 12 Apr 2016 13:35:26 -0700 (PDT)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 1F89A12D7E9 for <stir@ietf.org>; Tue, 12 Apr 2016 13:35:26 -0700 (PDT)
Received: (qmail 3345 invoked by uid 0); 12 Apr 2016 20:35:24 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 12 Apr 2016 20:35:24 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id hYbH1s0171MNPNq01YbL1t; Tue, 12 Apr 2016 14:35:24 -0600
X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=w1VtefKfAAAA:8 a=0FD05c-RAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=Z80JlwQ0AAAA:8 a=tGX7uwomAAAA:8 a=8pif782wAAAA:8 a=hGBaWAWWAAAA:8 a=MVff1mliAAAA:8 a=0vhXp1a2ptINoiIBi3AA:9 a=6bONJYkkPyJeyrc5:21 a=gA5azET7QJtY3MYt:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=6-C5ikvthBEA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date; bh=O3VV1tFzPKABVVMcopFiSXkZEuaGtmSBSYJt8ddmJiQ=; b=WryQfuhqDXBScsrzIF6iJV38xg Oa3CvaKzFdlrFE7mVtZveiZZpgGVKa/VtnfXWULNVH3Pz6Qh4FTrK8TlvR3QGYDRzfYjOwGtiTOvM WQhf/plFsT2yGHKuij3LZCMAi;
Received: from [100.36.35.60] (port=57076 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from <richard@shockey.us>) id 1aq51p-0006UT-CU; Tue, 12 Apr 2016 14:35:17 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.160212
Date: Tue, 12 Apr 2016 16:35:09 -0400
From: Richard Shockey <richard@shockey.us>
To: Chris Wendt <chris-ietf@chriswendt.net>, John Mattsson <john.mattsson@ericsson.com>
Message-ID: <56652A44-7ED0-4F57-A071-93FA48FA0DE4@shockey.us>
Thread-Topic: [stir] Choice of STIR signature algorithm
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> <F4F09888-780B-4725-9A74-AD2EF661C5C0@vigilsec.com> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> <BB4B8171-BF3E-4D3F-B81B-73AC9768ED75@shockey.us> <D3316C0C.485E4%john.mattsson@ericsson.com> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net>
In-Reply-To: <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us}
Archived-At: <http://mailarchive.ietf.org/arch/msg/stir/74ZBYJxjgJj7HFvSe_Zu6mJ2Ul0>
Cc: "stir@ietf.org" <stir@ietf.org>
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, 12 Apr 2016 20:35:34 -0000

Excellent discussion.  But what I will insist on in further draft revisions is less rhetoric and more implementation examples. Do this .. look for that. Were working on how to display the data to the UA> 




We have to show where in the INVITE this stuff SHOULD be inserted and what it might look like to give guidance to implementers on what to look for. The rest is policy and we are not going there .not now not ever. 


I could care less about root CA issues since no one in the IETF is going to decide those problems if target address involves E.164 within national boundries. No one is going to tell the US, British, Swedish or French governments how the plan to secure their voice networks. The body of law here is indisputable. 


On 4/12/16, 12:31 PM, "stir on behalf of Chris Wendt" <stir-bounces@ietf.org on behalf of chris-ietf@chriswendt.net> wrote:

>Hi John,
>
>I’d be happy to get RS256 and ES256 with a preference to the later.
>
>To add PS256, i’d defer to others opinions.
>
>RS256 has a simple advantage that it’s commonly implemented in most JWT libraries today.  But that’s not necessarily a a great justification.
>
>Beyond that, particularly after creating some example tokens and seeing the very compact size of the signature, I have a big preference for ES256 as the default from the size and CPU advantage, so I’m less opinionated on PS256 as another option or replacing RS256.
>
>Just as a preview:
>
>ES256 based token:
>eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IkVTMjU2IiwieDV1IjoiaHR0cHM6Ly9j
>ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNydCJ9
>.
>eyJpYXQiOiIxNDQzMjA4MzQ1Iiwib3RuIjoiMTIxNTU1NTEyMTIiLCJkdXJpIjoi
>c2lwOmFsaWNlQGV4YW1wbGUuY29tIn0
>.
>KK89q2RFY-BkKQQhiB0z6-fIaFUy6NDyUboKXOix9XnYLxTCjdw1UHjCbw4CefeK
>wH_t7W-bnGlZz4pI-rMjfQ
>
>RS256 based token:
>eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IlJTMjU2IiwieDV1IjoiaHR0cHM6Ly9j
>ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNydCJ9
>.
>eyJpYXQiOiIxNDQzMjA4MzQ1Iiwib3RuIjoiMTIxNTU1NTEyMTIiLCJkdXJpIjoi
>c2lwOmFsaWNlQGV4YW1wbGUuY29tIn0
>.
>AaeXRqm7kHnkZu2j6cQmDCiomZRiaE55bYWhFgnX8xMqpBFq96M0xgMM5OLa9_LM
>rkuKv2ivK5GZz8OlFrmAirucRlAh8YdUkj5Cr5xPRr-gg9acD9jqJUnQ-ZxpL1yq
>-FFVLhvpbsE5NMPHXUp5lpt62rD-S0NlhwHNCeMqZHxt6T5BmZBXITEd1PRRij_6
>FhE3wxWEhZMthWJuEbcPpRMZDu-R7lTNddn62nUKjn3s00R3gm25Dto5Z0dzfQpA
>ysJvnbc1QRimfsYqJPUFc57lnglVLf4WrpeZCc8-LcoXeSr_dseDgsrmg2EuHmn5
>h1nTOmLgF16ZHm121ZVjiXz2sMFvs9RaIxw0AFkM7rnV56OxAFCRuzMNldiEVf8p
>lRZVvqZ4BfVQlCNXNyyVgPOUtNr3ta6yD2H0oANQvvHtwjuSwB9Kruj4Wsu5N7Ik
>i4MBs6SWJDmcUV-NW_AHYLaao-IvFVe4oCkJNjsqwwXuLv1TO2sDHdc5sQO5zm21
>019PPxw1udHVtywsRVNKLo0RzE0TqYUF7XclCDur7MMOx9SnStV2PFIM7Jejyn9x
>54RtJEjOnchaSalfIFr_UXqXgVmRZVTzLDQIlcmHjlhhLnCnNx3sYsAANen8Y8jt
>fgJ2ewjGotB4Lq8VYe1FacBKKk0VyCfImXba0u1hB8Q
>
>-Chris
>
>> On Apr 11, 2016, at 9:19 AM, John Mattsson <john.mattsson@ericsson.com> wrote:
>> 
>> I don’t know why so much of the discussion during the Tuesday meeting was
>> about root certificates. As Eric pointed out on the mail, it is not hard
>> to get a ECDSA certificate as Digicert, Entrust, Globalising, Symantec,
>> Certicom, Comodo, and soon Let’s encrypt will happily give you one. As
>> Russ pointed out most (or all) of these ECDSA certificates will be signed
>> by a RSA root certificate. But root certificates and verification of the
>> credentials seems to be out of scope of STIR and does not affect the
>> PASSporT object. As far as I understand, the only thing STIR should
>> specify is verification of the PASSporT object.
>> 
>> If we mandate RSA in addition to ECC (which I don’t think is necessary,
>> but do not oppose), then I think that RS256 (PKCS1-v1_5) is the wrong
>> algorithm. Both TLS 1.3 (draft-ietf-tls-tls13) and IPSec
>> (draft-ietf-ipsecme-rfc4307bis) are replacing PKCS1-v1_5 with PSS (JOSE
>> alg PS256). If STIR uses RSA, it should do the same.
>> 
>> If STIR uses RS256 (PKCS1-v1_5) for backward compatibility (which I don’t
>> see as necessary as RFC4474 is not deployed) then this should be clearly
>> stated, and RS256 (PKCS1-v1_5) should be NOT RECOMMENDED.
>> 
>> 
>> Cheers,
>> John
>> 
>> 
>> 
>> On 07/04/16 21:43, "stir on behalf of Richard Shockey"
>> <stir-bounces@ietf.org on behalf of richard@shockey.us> wrote:
>> 
>>> 
>>> On 4/7/16, 8:04 AM, "Chris Wendt" <chris-ietf@chriswendt.net> 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 <richard@shockey.us>
>>>>> 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 +1 703-593-2683
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 4/6/16, 12:09 PM, "stir on behalf of Robert Sparks"
>>>>> <stir-bounces@ietf.org on behalf of rjsparks@nostrum.com> 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"
>>>>>>> <stir-bounces@ietf.org on behalf of housley@vigilsec.com> 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 <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
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>> 
>>>>> _______________________________________________
>>>>> 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