Re: [stir] Choice of STIR signature algorithm

"Peterson, Jon" <jon.peterson@neustar.biz> Thu, 12 May 2016 04:58 UTC

Return-Path: <jon.peterson@neustar.biz>
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 4665412B031 for <stir@ietfa.amsl.com>; Wed, 11 May 2016 21:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.601
X-Spam-Level:
X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
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 1BGKnUj8rBxn for <stir@ietfa.amsl.com>; Wed, 11 May 2016 21:58:00 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B43A12D13A for <stir@ietf.org>; Wed, 11 May 2016 21:58:00 -0700 (PDT)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u49INegt021459; Mon, 9 May 2016 14:25:37 -0400
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 22scfscuxg-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 09 May 2016 14:25:37 -0400
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Mon, 9 May 2016 14:25:35 -0400
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: Eric Burger <eburger@standardstrack.com>, IETF STIR Mail List <stir@ietf.org>
Thread-Topic: [stir] Choice of STIR signature algorithm
Thread-Index: AQHRj2YTntt3b3ZzjUyODuhm37BkpJ98ERYAgAALlICAABNkgIAADpcAgAEjIgCAAJc0gIAAtpUAgADUA4CABYofAIAByB0AgABKUACAJUhzgIAEhq+A
Date: Mon, 09 May 2016 18:25:35 +0000
Message-ID: <D35622EC.18AA82%jon.peterson@neustar.biz>
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> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com>
In-Reply-To: <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.3.160329
x-originating-ip: [10.96.12.151]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <3597E5BC7B2A694F9C9FC6CBCB4FA890@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-09_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1605090265
Archived-At: <http://mailarchive.ietf.org/arch/msg/stir/YZhzADti3qhp2zBA-fSKcIE5ISo>
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, 12 May 2016 04:58:02 -0000

Russ's assertion that "for quite some time we will need to be able to
validate RSA PKCS#1 v1.5 signatures" would lead me to think RSA should
remain a MUST.

As I said in Buenos Aires, I am deferring to Russ, and Sean, and EKR, and
the other people who live and breathe this world to provide us guidance. I
asked Sean to write the text for this.

Jon Peterson
Neustar, Inc.

On 5/6/16, 7:18 AM, "stir on behalf of Eric Burger" <stir-bounces@ietf.org
on behalf of eburger@standardstrack.com> wrote:

>FINALLY, a cogent *engineering* reason for needing RSA.
>
>How about:
>	MUST support ECDSA
>	SHOULD support RSA unless you know you will not need it
>
>Rationale:
>ECDSA is ubiquitous today. ECDSA has lots of deployment advantages.
>Pretty much everything else s*cks in comparison.
>
>However, especially for delegated certificates, there is a chance that
>one of the intermediate certificates will not be signed with ECDSA but
>with RSA. As such, if you know you will be deployed in such an
>environment, RSA is OK.
>
>I would also suggest putting in a toxic waste warning in the document
>that the support of RSA is *not* a built-in downgrade attack. This is
>something that is covered by policy, not necessarily engineering. As
>such, a note to the implementor suggesting that if they know they should
>only see ECDSA (or better) signatures, they can feel free to reject an
>INVITE signed with RSA, even if it looks legitimate.
>
>> On Apr 12, 2016, at 4:57 PM, Russ Housley <housley@vigilsec.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.
>> 
>> We will need to say that the validation will include RFC 5280 path
>>validation to a trust anchor.  This means that the signature on each
>>certificate will be validated.  So, for quite some time we will need to
>>be able to validate RSA PKCS#1 v1.5 signatures, either on the PASSporT
>>object or on a certificate, even if we state a strong preference for
>>ECDSA.
>> 
>> Russ
>> 
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>