From nobody Fri May 6 07:18:37 2016 Return-Path: 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 2BD7A12D5FC for ; Fri, 6 May 2016 07:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com 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 tZCV-nmN1XQz for ; Fri, 6 May 2016 07:18:34 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3A712D0F4 for ; Fri, 6 May 2016 07:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type; bh=qoL0QjxkAH4ZJovhmsuYCapyRWuaA79oB6LIyH7KYTc=; b=s29BwV9RszHIqqMt5CCoeB580w A4CHuUnaibSySU2068FMfIKt6yrwtoC1wzT+BU90iAp9wYbpRYAbBtjDElZF+3PRyAanKtEXagWSa 3Dqsk2JcbJ+hG4E9LkkdSyl7b6qZ6kCE8GiVAqCRRQ6WYgmsblXIrwbMT63Y2xkQIk24=; Received: from [141.161.133.176] (port=52932 helo=[10.129.225.145]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1aygaM-0003i3-3c for stir@ietf.org; Fri, 06 May 2016 07:18:34 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_08F41927-89DF-4853-A5F7-C98338DB3445"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> Date: Fri, 6 May 2016 10:18:27 -0400 Message-Id: <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 14:18:36 -0000 --Apple-Mail=_08F41927-89DF-4853-A5F7-C98338DB3445 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 = wrote: >=20 >=20 >> I don=92t 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=92s 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. >=20 > 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. >=20 > Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_08F41927-89DF-4853-A5F7-C98338DB3445 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXLKezAAoJEORoZaSQsc1ItVcQAK0iFFvT0DiEOt08Zt8NjxH1 ybhPEh+wOnt+gbUGojP/i66xFlsOFjU1rABqTbb9qKDX2eJAlAjiACbpHKLdrEpq ZzHP2+zO59xqqyxKs8WZAMtYgf+lAv0WaFqTShYCLvnjuD083+PtjMOcLFZbB5Hk a3dYHHnqZwsM0sA2mIxpA81vu6Fdh6qI6QMF7pq2UifWlam0qFzgWJtCvj4uEWAj D6CK06T5QYvPvP/klCWzrcnoAIVY+DCY6BmBvhCSwhhECZ0bRckZDo1RiXsMwG34 l4wnBK2dH1wYv4fHWdRTFiHlACRV8wpVOZtwjjZSeDWYNWkrxupYzuC/H6EKMMuN SW/zIHd07np+Cy8v4P1609clV1lZmTx6LeV4UXO22wDUUhY8Pa/aT5Pr3z2YwrXk eT/ol7sQ0P3oSSpXcNKtaod1mOSanR/IQb7Vdq0QfTxyVs6WEM/zhrTa3sLeiE0e Op6JaKGhen6RkQNs0AATxUuVUHPkxAqVxO3qUbne/RoU11F19JDFsfV8SFLUwGFS SL1Zcs6MfrVwtVJYAsSK5oBUaWqSMfnxndLJbJDHYKntQQ3FQQ3HYS5TGISYhZUP 4io8MlLDESsufKQlo1Cf8Gu1p0dWnUFVubW/cOGgAmluefEOKymha3LpBUl7hyoR /zY+jgQs59yKbNFYCkcv =FvUZ -----END PGP SIGNATURE----- --Apple-Mail=_08F41927-89DF-4853-A5F7-C98338DB3445-- From nobody Fri May 6 07:27:33 2016 Return-Path: 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 3503C12D609 for ; Fri, 6 May 2016 07:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com 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 grrWP14-59mr for ; Fri, 6 May 2016 07:27:31 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1CCA12D600 for ; Fri, 6 May 2016 07:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type; bh=AwVQC7Z+Eo+8IgO3ZkoEn2wPcGcQYUbbqNIHTiAARr4=; b=N8j6aNN+j8pJqIIq9H332lbjB9 oHjbKeA/Q2qzxY+/IVWlWT2dE6fFjrbJm6bC8S7JieXOkymfpTEsBmIzRZRIQtOs4QEjZAKCXsquw 9f5U2pPhMK9AbZaXAwlxVktOSWkI0v8btbZ3EVf27VBX6iZ3kgm5BGgDX5P0/gOfO//M=; Received: from [141.161.133.176] (port=39939 helo=[10.129.225.145]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1aygj3-0008Sr-8g for stir@ietf.org; Fri, 06 May 2016 07:27:30 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_D77025E5-83CE-40F3-A67F-35FDD3AC1B22"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: Date: Fri, 6 May 2016 10:27:28 -0400 Message-Id: <352435FE-012E-481C-84F4-6D6342D1483B@standardstrack.com> References: To: IETF STIR Mail List X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [stir] Brief review of draft-ietf-stir-rfc4474bis-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 14:27:32 -0000 --Apple-Mail=_D77025E5-83CE-40F3-A67F-35FDD3AC1B22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Typically sits, but does not always sit. That was a matter for great = debate. Clearly we need clearer language. > On Apr 30, 2016, at 4:35 PM, Alan Ford wrote: >=20 > - Section 4, it took me a while to realise that the authentication = service typically sat as a component of Alice's home SIP proxy. Whilst = obvious once a bit more context was available, I'd suggest adding a = sentence at the end of paragraph 5 (The proxy, ...) that reads something = like "The proxy then forwards the request under normal to Bob's domain". --Apple-Mail=_D77025E5-83CE-40F3-A67F-35FDD3AC1B22 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXLKnQAAoJEORoZaSQsc1ILgMQANhsQVOXTpOtmthFrGjMZMLL YQl36D4yFYgg2jwVjnR7j6Gb0sds5r6kyrmyEm776+ga0GI28wAQrK1K/+giBeBV t6c085vtRe04STi9MQfH4ckGE/RKTGyUcw18YZTv2jmgZm7e4/x67v10M3gsq2Gt KbuxxDJf3LAjkF90f3eZU6mctA1wuzrqlxoV+/llK73YKk82xzBZsA6g6FyOifO2 tyOOsWlttK+juxNu+v+vIJG3xz3SSIc4cgT+9jZMC1gvu12CwFfIdM6v4DhmOY3B E/kJTdsIdYR+iYJkK9NtYg9HuTeDh/4nV+x7pQ46jUCh2DuBVuevWY5I7JIpBc2X l1ba2siTW7HyuN58S3XObZAWMOrbIwr8792S4tYdhWfiRPcU74DStTGTuyIXiuDv e8spa4ZkOVg190hJ1N7F7VWGUZNsR7Kz9aOoWETBXtuc05T5yUzSzNqJsP/f1ZdT BECgqyijuigVL9fYnBbh+zSgQTnukXcGJLSiAZG7Q83CrhofazkqW31uZyDEXNSH mVO5BtSh4rN1bSQRbih45kjDA4+YSRZF5VsYnQa5ZeveABNEdCGZB3zQIcSqcyxP eaVhgHPCaoZQXJ3vO1R5DIkNt2u3WCh6u3gaMKVNTSNcaL+tb7gLP/vO9/z3CSAG pAik1bskST45Us1RfvKc =cPhD -----END PGP SIGNATURE----- --Apple-Mail=_D77025E5-83CE-40F3-A67F-35FDD3AC1B22-- From nobody Mon May 9 13:05:04 2016 Return-Path: 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 3889C12D0E7 for ; Mon, 9 May 2016 13:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 4KXRAdsFqJPO for ; Mon, 9 May 2016 13:04:59 -0700 (PDT) Received: from smtp90.ord1c.emailsrvr.com (smtp90.ord1c.emailsrvr.com [108.166.43.90]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1381312D147 for ; Mon, 9 May 2016 13:04:59 -0700 (PDT) Received: from smtp4.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 769A218060C for ; Mon, 9 May 2016 16:04:58 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 27A131805BD for ; Mon, 9 May 2016 16:04:57 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Mon, 09 May 2016 16:04:58 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 9 May 2016 14:04:59 -0600 To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [stir] STIR and WebRTC X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 20:05:01 -0000 I've been looking at how WebRTC Identity and STIR work together and put = together a worked out example at=20 http://www.ietf.org/id/draft-jennings-stir-rtcweb-identity-00.txt It does not propose any significant changes to STIR content but it does = point at a few syntax changes that might make things easier.=20 One is to include the type of identity assertion in the SDP a=3Didentity = as extra parameters so they would look like=20 a=3Didentity:eyJhc3NlNzcG9ydHYxIn19;protocol=3Dpassport Another could be to get WebRTC and STIR to use a common syntax to = represent the DTLS-SRTP fingerprint.=20 Love to get feedback if people see any problems with these types of = changes to STIR.=20 Thanks, Cullen From nobody Mon May 9 13:37:19 2016 Return-Path: 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 D2EED12D150 for ; Mon, 9 May 2016 13:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XJ07eZT7-v8z for ; Mon, 9 May 2016 13:37:16 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D48C812D110 for ; Mon, 9 May 2016 13:37:15 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id A916FF24036; Mon, 9 May 2016 16:37:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id v4SblNLV7o-L; Mon, 9 May 2016 16:20:34 -0400 (EDT) Received: from [10.128.112.181] (unknown [207.43.147.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 157E2F24013; Mon, 9 May 2016 16:37:15 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> Date: Mon, 9 May 2016 16:37:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 20:37:18 -0000 I would rather be a bit more granular. MUST support ECDSA for PASSporT signatures SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures and MUST support ECDSA for certificate signatures MUST support RSA PKCS#1 v1.5 for certificate signatures Then, we should say something to product planners that at some point in = the future, we expect support for RSA to be downgraded. Russ On May 6, 2016, at 10:18 AM, Eric Burger = wrote: > FINALLY, a cogent *engineering* reason for needing RSA. >=20 > How about: > MUST support ECDSA > SHOULD support RSA unless you know you will not need it >=20 > Rationale: > ECDSA is ubiquitous today. ECDSA has lots of deployment advantages. = Pretty much everything else s*cks in comparison. >=20 > 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. >=20 > 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. >=20 >> On Apr 12, 2016, at 4:57 PM, Russ Housley = wrote: >>=20 >>=20 >>> I don=92t 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=92s 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. >>=20 >> 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. >>=20 >> Russ >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon May 9 14:31:14 2016 Return-Path: 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 C48B012B02B for ; Mon, 9 May 2016 14:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com 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 u_CK8bJZGDt2 for ; Mon, 9 May 2016 14:31:11 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1250C12B00A for ; Mon, 9 May 2016 14:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type; bh=H7QIGQPmzT8+WAlnwvq36QqPnA9kbstOl42aim0W5Ro=; b=Iy7nCNY07KkBP6TAo2IHeHxQX2 NcMvnxWR+mWyEwaC7DmzsQIn4UBgQhX7JprhcGhND6hnujDzYJMd/7HemZ0JC6tYWUpVJnstc3h9+ 1NUkWlTs3ruLtbNPrQF4der0fXNZddZZl0PGq5+kjhcH+tBjnI2uqoX39BXX8sN7iSiQ=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:54536 helo=[192.168.15.108]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1azsle-0007uR-Ff for stir@ietf.org; Mon, 09 May 2016 14:31:10 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_1B129A07-4FB4-429C-BEEC-59001B896E55"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: Date: Mon, 9 May 2016 17:31:03 -0400 Message-Id: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 21:31:13 -0000 --Apple-Mail=_1B129A07-4FB4-429C-BEEC-59001B896E55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sounds good. > On May 9, 2016, at 4:37 PM, Russ Housley wrote: >=20 > I would rather be a bit more granular. >=20 > MUST support ECDSA for PASSporT signatures > SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures >=20 > and >=20 > MUST support ECDSA for certificate signatures > MUST support RSA PKCS#1 v1.5 for certificate signatures >=20 > Then, we should say something to product planners that at some point = in the future, we expect support for RSA to be downgraded. >=20 > Russ >=20 >=20 > On May 6, 2016, at 10:18 AM, Eric Burger = wrote: >=20 >> FINALLY, a cogent *engineering* reason for needing RSA. >>=20 >> How about: >> MUST support ECDSA >> SHOULD support RSA unless you know you will not need it >>=20 >> Rationale: >> ECDSA is ubiquitous today. ECDSA has lots of deployment advantages. = Pretty much everything else s*cks in comparison. >>=20 >> 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. >>=20 >> 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. >>=20 >>> On Apr 12, 2016, at 4:57 PM, Russ Housley = wrote: >>>=20 >>>=20 >>>> I don=92t 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=92s 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. >>>=20 >>> 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. >>>=20 >>> Russ >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 --Apple-Mail=_1B129A07-4FB4-429C-BEEC-59001B896E55 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXMQGYAAoJEORoZaSQsc1I5jsQAJd+8IJ4faUBiUZdyT/tPeZ1 n63YR1SnyZlmywD0+czQ402Xb5Wh4XIw5c5tdSSM3eL8zFCq+ImrnMy+ZdRnOyWm rEsn4WgNWMXFzjIBdbgvuG494bpoEedF5n475eI3EpXYCQnLAC0prcB4rH6AxemT mVixBTjselyR+t6hTCgTHOcsbPugiBSzOApDc3wZWwUYX7TBY1sHS2EtX9jHA5SU 893hcmGuU5d9OBWK9lzocYfthxGRw5wD1M7IWK6Jm+6P3Lg0719ForIkvx9Bf86R 5N1Dtm+JX/IbZFoEdQtJVlhyDgWX30IGnau58g1cJaZddvLoKUhlZjZAF+NmECqm uYoP3QaCiYc+I/sCtBpefLeCJqDUQ6cBYzb43hXTYiURhiwG35O1URZ16SyBxc/m +o0etQJ3pV/Z/JA4vIQoqReow8TpQ7EHW5GAeKsskzhQZkLXEFj0pZZy60bAVEPi 9rBg8nCIuAgNB8eKup24JS7+vx7Dc+aizrsP3vb5zNrpWri/nga17usa2LfEA0aU VLlOK4SYeKmOj6Uo66z/XA41a4MU1R8F0AaE5hjJ6iA3vFJrLhrDLU8e5MysXQsZ dmRw3RJi0nWX27c+VGdd24iSAs3771qszliiCBlw4yeXUzSU1aDQ5Unt67i510DN drJmb955w2bQgQ6nvva2 =nx9M -----END PGP SIGNATURE----- --Apple-Mail=_1B129A07-4FB4-429C-BEEC-59001B896E55-- From nobody Tue May 10 08:23:30 2016 Return-Path: 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 C725812D726 for ; Tue, 10 May 2016 08:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com 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 CJh2nJFoYzpm for ; Tue, 10 May 2016 08:23:27 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D599E12D728 for ; Tue, 10 May 2016 08:23:12 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id 90so8235369qgz.1 for ; Tue, 10 May 2016 08:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t49TVAJ6f6Ishln7Hlte8hm53KJcmYmCJTz23oyLPoY=; b=qszNPkWoA3Nb9jOHhM9+NZ4Wn0vCgn1kS0djMTV1EdXowYyCUoXQuB7K1T7Mf0wwPu 0Byxrcg0j/F4QnHoCH+D8Zu/M1UvvCPEYmlI6tVgu9jFGA0bg9sZkswwmlKg8vqepfSC +Obh9Y3PHA6YhT0DxmGx+V9RUwnQeiPJrvGsUoZXV1oqf25XLedgrsi3DzYpt/vd/KzA hN88HTX5gNbpJ/3sVn3bZpep4EdvS2soh4p5ICyrsjssJcea+uaEqfi/+NZ7fD7++oq1 glOO6zdwRz1LR+9cFtKzJocuk8v9mcVQ3EJl1Rm7JhNvl5GofX3lG3BF2Omng2/Jk1BU 2EpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t49TVAJ6f6Ishln7Hlte8hm53KJcmYmCJTz23oyLPoY=; b=mCO87cdFhbwePUME58nsRL/Hcva/kk+qK9CIZNWH/jxNPMl8hVf6lSGLXGYYNOaNVD L05ayYlFLogMrSTS0NQRi37jsa+kQltj8Iw08tYWPnPiORsoGCech2gwTsPwAn/wC9HS 1hnFeO+dfAHMBCQClMImue7MYiW1UiZmM+WWDjsP2O6LODsDj6LgEqIFacTJcwzyZUvg /lOlTxtWsXfhfOxWQ9vGa1Tz3i9YQX4gKUr3uU3+utyjawHjKcfOhd6rxAglmvHQU0Nm /o8D03lVrZmh4YdeknDuKOkYuomSlAmAfA7gXNwzLELjbAvE7J4j9lGxgFQdItK3ok3e JE4A== X-Gm-Message-State: AOPr4FVFYbI7mgAu0upTspX7wGl1ODGF83ZIN4SSM7NvHQVJeWOPBTzG1AD/h7Trt1PHIw== X-Received: by 10.140.174.86 with SMTP id u83mr42480845qhu.35.1462893792002; Tue, 10 May 2016 08:23:12 -0700 (PDT) Received: from ?IPv6:2601:a40:100:d3:a8fa:c4a3:35b2:fe64? ([2601:a40:100:d3:a8fa:c4a3:35b2:fe64]) by smtp.gmail.com with ESMTPSA id o130sm1112199qho.17.2016.05.10.08.23.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 May 2016 08:23:11 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: Date: Tue, 10 May 2016 11:23:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF STIR Mail List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 15:23:30 -0000 +1 > On May 9, 2016, at 5:31 PM, Eric Burger = wrote: >=20 > Sounds good. >=20 >> On May 9, 2016, at 4:37 PM, Russ Housley = wrote: >>=20 >> I would rather be a bit more granular. >>=20 >> MUST support ECDSA for PASSporT signatures >> SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures >>=20 >> and >>=20 >> MUST support ECDSA for certificate signatures >> MUST support RSA PKCS#1 v1.5 for certificate signatures >>=20 >> Then, we should say something to product planners that at some point = in the future, we expect support for RSA to be downgraded. >>=20 >> Russ >>=20 >>=20 >> On May 6, 2016, at 10:18 AM, Eric Burger = wrote: >>=20 >>> FINALLY, a cogent *engineering* reason for needing RSA. >>>=20 >>> How about: >>> MUST support ECDSA >>> SHOULD support RSA unless you know you will not need it >>>=20 >>> Rationale: >>> ECDSA is ubiquitous today. ECDSA has lots of deployment advantages. = Pretty much everything else s*cks in comparison. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>> On Apr 12, 2016, at 4:57 PM, Russ Housley = wrote: >>>>=20 >>>>=20 >>>>> I don=92t 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=92s 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. >>>>=20 >>>> 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. >>>>=20 >>>> Russ >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed May 11 21:58:03 2016 Return-Path: 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 ; 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 ; 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 ; 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" To: Eric Burger , IETF STIR Mail List Thread-Topic: [stir] Choice of STIR signature algorithm Thread-Index: AQHRj2YTntt3b3ZzjUyODuhm37BkpJ98ERYAgAALlICAABNkgIAADpcAgAEjIgCAAJc0gIAAtpUAgADUA4CABYofAIAByB0AgABKUACAJUhzgIAEhq+A Date: Mon, 9 May 2016 18:25:35 +0000 Message-ID: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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 wrote: >>=20 >>=20 >>> I don=B9t 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=B9s encrypt will happily give you one. A= s >>> 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. >>=20 >> 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. >>=20 >> Russ >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > From nobody Wed May 11 21:59:13 2016 Return-Path: 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 EA27E12D149 for ; Wed, 11 May 2016 21:59:12 -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 EzKcJjF4PaZn for ; Wed, 11 May 2016 21:59:11 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 E15A312D13A for ; Wed, 11 May 2016 21:59:10 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u49ICa0J009837; Mon, 9 May 2016 14:19:52 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 22scpd4qbh-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 09 May 2016 14:19:52 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.235]) with mapi id 14.03.0279.002; Mon, 9 May 2016 14:19:52 -0400 From: "Peterson, Jon" To: Alan Ford , "stir@ietf.org" Thread-Topic: [stir] Brief review of draft-ietf-stir-rfc4474bis-08 Thread-Index: AQHRox/P+zsaKnVLN06sLYY3r9Lf2p+wxjSA Date: Mon, 9 May 2016 18:19:52 +0000 Message-ID: References: In-Reply-To: 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="us-ascii" Content-ID: <5307E479A91B494894ABB6ABC056C70B@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-1605090262 Archived-At: Subject: Re: [stir] Brief review of draft-ietf-stir-rfc4474bis-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 04:59:13 -0000 Thanks Alan, these are useful comments. I can try to clarify the language a bit about the authentication service. As RFC4474bis says (in language it inherits from RFC4474), we based the authentication service on the abstract "location service" concept in baseline RFC3261 which is similarly and intentionally vague in its relationship to any given SIP component. I am aware that some implementations of RFC4474bis are already decomposing the authentication service into a stub in the proxy that contacts a RESTful web service which in turn generates the PASSporT object and passes it back over HTTP to the proxy. I do want to make sure any language we add doesn't rule out implementations like that, which seem like useful ones. I have been hearing that we need to put in some clearer language about 438 and other response codes that are grandfathered in from RFC4474, in particular to explain how they might differ now. I think the semantics is largely the same, but there are a few issues: e.g., we don't want a response code status line for "Bad Identity-Info" when in fact the Identity-Info header has been deprecated in favor of the "info=3D" parameter. The next revision will clean those things up a bit. The issue of distributing private keys to virtual hosting systems and so forth is a known hard problem, and scoping the credential solely to SIP doesn't really give us much relief. I'm holding out for a general solution, possibly as a result of the LURK BoF we saw in Buenos Aires. Your smaller fixes I'll fix. Jon Peterson Neustar, Inc. On 4/30/16, 1:35 PM, "stir on behalf of Alan Ford" wrote: >Hi all, > >At IETF95, Robert suggested I should review draft-ietf-stir-rfc4474bis >from an implementer's point-of-view... So I have :) I was coming at this >completely fresh - I had never read any of the document before and had >very limited background on this topic... And I must first say it's a >really accessible document, very easy to follow and understand. I have >only a few very minor comments on clarity: > >- Section 4, it took me a while to realise that the authentication >service typically sat as a component of Alice's home SIP proxy. Whilst >obvious once a bit more context was available, I'd suggest adding a >sentence at the end of paragraph 5 (The proxy, ...) that reads something >like "The proxy then forwards the request under normal to Bob's domain". > >- Section 5.1, Step 4, paragraph 3... Similarly, just insert "at the >receiver" after "In some cases, a request sent through an authentication >service will be rejected by the verification service" - helps make the >process a little clearer. > >- Section 5.2, it is not clear if there should be anything different in >the 488 for no Identity header, and unsupported ppt? > >- Section 6.3, typo "bae64" > >- Section 6.3, "result of the JSON object construction process", would it >not be clearer to say "the PASSporT object" or similar? There is a clear >definition of "canon" in the last paragraph of Section 8 which could be >used earlier too. > >- Section 6.4, "URL of the form" ? Is form the right word for >content-type here? > >- Section 6.4 references "this registry" -> what registry? Maybe this >should reference IANA section? Also the ref to RFC7519 to define "RS256" >should probably occur here. > >- Section 7.2 - could the use of the key not in some way be restricted >purely for use with SIP Identity? Therefore removing issues with giving >it to a third-party service provider? > >- Section 12.1, paragraph 4: "The To helps" and "over the To" -> insert >"header" after "To" for clarity since it scans really strangely otherwise! > >Cheers, >Alan > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Sun May 15 08:37:42 2016 Return-Path: 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 B8A4612D1E2 for ; Sun, 15 May 2016 08:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 yMdaiVFRDLvp for ; Sun, 15 May 2016 08:37:38 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7312812D1DD for ; Sun, 15 May 2016 08:37:38 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id g133so142095226ywb.2 for ; Sun, 15 May 2016 08:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mbUHxd310axir2BkcVBU6/H2KV850GAbPhqGKLsIn48=; b=dVONaG2QVTLFCzMjDEBlIFPMIB0jQdZNWynhv195yyf1mYd10SakhV5fSj8Q1nOEqy ByNfXOqUMCB9Fkh2UKzGnEjaeC75WvnFLpY3UAQG2VjoUFtDKHjiVp4AINSqvihxOGDb vd0ZIasDpL6f9bsZVVHCNQKG0aE0joHqzq4+Cc4/6YpNpksWlHSrmKGSwuhUPmkUCfGz FUgLyDs+1Rp3TwAbf/uvYm5EYeOK4q1C81WsFIGrFmzVp9D2NPZ8yLt1PultKmc+SdD3 KKciVG5piLrTsAWJpNgRwuQPiltxFjuyl4qQXstpOUuTlPUzOAVt/yZeBNV+2/UrhiOF QW4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mbUHxd310axir2BkcVBU6/H2KV850GAbPhqGKLsIn48=; b=HtyZlsCwt9Af/DePJ0s7hB75Z+t+K2QO7nBAHjmVpMzNof0/bsIMfXRWS+VtMnzfgR NuIZjCNsGAiRoyJIlWc0JXh0mlK96DqnnjLxdwza9P52n4HcVRFEWDBlsVFb874YLH/X 9E6r8RY5qS8YI+2BoTN6uVdsyWDe8o1uJ50Ea5OwEOp72Mcg6DPINIzChzyjatVKlQOn zYHwUlDicS6m4+yxmKGSVzxyGbSuS+myw6dhGBgdN49NXsFKz2xsYYcajfgrcNRhx0tP pkhMB0kpuIm3P4u2spo7yaYIWHIzwIhHzSdyuy8DQ0ZQM0z+nKbhsxnnWTuExN4CX8uI u6lw== X-Gm-Message-State: AOPr4FXOti1Sz5/OLM2jqN5vpmJh+LJYrIE/T1IpDHOPSK2SHGjGXc2RoxLwCtG56x6lqz3VAXOWy5vqJIOhjg== X-Received: by 10.37.207.194 with SMTP id f185mr12180990ybg.82.1463326657683; Sun, 15 May 2016 08:37:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Sun, 15 May 2016 08:36:58 -0700 (PDT) In-Reply-To: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> From: Eric Rescorla Date: Sun, 15 May 2016 08:36:58 -0700 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=94eb2c0594ba9f54520532e3499e Archived-At: Cc: IETF STIR Mail List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 15:37:41 -0000 --94eb2c0594ba9f54520532e3499e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This seems largely reasonable. I would consider removing the SHOULD for RSA for PASSporT signatures, for two reasons: 1. There's no legacy to deal with 2. Because these objects are just sent out with no negotiation, it's not that useful to know that relying parties might or might not support your algorithm. The safe thing to do would be ECDSA. I would also note that the above doesn't specify a curve, but I assume we're talking P-256. -Ekr On Mon, May 9, 2016 at 1:37 PM, Russ Housley wrote: > I would rather be a bit more granular. > > MUST support ECDSA for PASSporT signatures > SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures > > and > > MUST support ECDSA for certificate signatures > MUST support RSA PKCS#1 v1.5 for certificate signatures > > Then, we should say something to product planners that at some point in > the future, we expect support for RSA to be downgraded. > > Russ > > > On May 6, 2016, at 10:18 AM, Eric Burger > 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 wi= th > RSA. As such, if you know you will be deployed in such an environment, RS= A > 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 s= ee > ECDSA (or better) signatures, they can feel free to reject an INVITE sign= ed > with RSA, even if it looks legitimate. > > > >> On Apr 12, 2016, at 4:57 PM, Russ Housley wrote= : > >> > >> > >>> I don=E2=80=99t 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, Symante= c, > >>> Certicom, Comodo, and soon Let=E2=80=99s encrypt will happily give yo= u 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 b= e > able to validate RSA PKCS#1 v1.5 signatures, either on the PASSporT objec= t > 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 > > > > _______________________________________________ > > 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 > --94eb2c0594ba9f54520532e3499e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems largely reasonable. I would consider removing t= he SHOULD for RSA for
PASSporT signatures, for two reasons:
<= br>
1. There's no legacy to deal with
2. Because th= ese objects are just sent out with no negotiation, it's not that useful=
to know that relying parties might or might not support your alg= orithm. The safe
thing to do would be ECDSA.

=
I would also note that the above doesn't specify a curve, but I as= sume we're talking
P-256.

-Ekr
=


On Mon, May 9, 2016 at 1:37 PM, Russ Housley <housley@vigilsec.com<= /a>> wrote:
I would rather be a= bit more granular.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST support ECDSA for PASSporT signatures
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SHOULD support RSA PKCS#1 v1.5 for PASSporT sig= natures

and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST support ECDSA for certificate signatures =C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST support RSA PKCS#1 v1.5 for certificate si= gnatures

Then, we should say something to product planners that at some point in the= future, we expect support for RSA to be downgraded.

Russ


On May 6, 2016, at 10:18 AM, Eric Burger <eburger@standardstrack.com> wrote:

> FINALLY, a cogent *engineering* reason for needing RSA.
>
> How about:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST support ECDSA
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD support RSA unless you know you will = not need it
>
> Rationale:
> ECDSA is ubiquitous today. ECDSA has lots of deployment advantages. Pr= etty 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 wit= h RSA. As such, if you know you will be deployed in such an environment, RS= A 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 somet= hing that is covered by policy, not necessarily engineering. As such, a not= e to the implementor suggesting that if they know they should only see ECDS= A (or better) signatures, they can feel free to reject an INVITE signed wit= h RSA, even if it looks legitimate.
>
>> On Apr 12, 2016, at 4:57 PM, Russ Housley <housley@vigilsec.com> wrote:
>>
>>
>>> I don=E2=80=99t know why so much of the discussion during the = Tuesday meeting was
>>> about root certificates. As Eric pointed out on the mail, it i= s not hard
>>> to get a ECDSA certificate as Digicert, Entrust, Globalising, = Symantec,
>>> Certicom, Comodo, and soon Let=E2=80=99s encrypt will happily = give you one. As
>>> Russ pointed out most (or all) of these ECDSA certificates wil= l be signed
>>> by a RSA root certificate. But root certificates and verificat= ion of the
>>> credentials seems to be out of scope of STIR and does not affe= ct the
>>> PASSporT object. As far as I understand, the only thing STIR s= hould
>>> 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.=C2=A0 This means that the signature on each = certificate will be validated.=C2=A0 So, for quite some time we will need t= o be able to validate RSA PKCS#1 v1.5 signatures, either on the PASSporT ob= ject 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 >
> _______________________________________________
> 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

--94eb2c0594ba9f54520532e3499e-- From nobody Mon May 16 14:01:56 2016 Return-Path: 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 ED88812DA6A for ; Mon, 16 May 2016 14:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 FZJgfkwceDot for ; Mon, 16 May 2016 14:01:53 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3655412DA6E for ; Mon, 16 May 2016 14:01:53 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 11C86F2402E; Mon, 16 May 2016 17:01:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id rnC2uN8B4JBn; Mon, 16 May 2016 16:44:44 -0400 (EDT) Received: from [192.168.7.153] (70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net [70.91.193.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 6170CF24013; Mon, 16 May 2016 17:01:52 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6ADA6AA5-3243-40C0-85A6-6DA3B71DCDFD" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 16 May 2016 17:01:51 -0400 Message-Id: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 21:01:55 -0000 --Apple-Mail=_6ADA6AA5-3243-40C0-85A6-6DA3B71DCDFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eric: I was thinking P-256, but I could be talked into: MUST support P-256 SHOULD support P-384 Russ On May 15, 2016, at 11:36 AM, Eric Rescorla wrote: > This seems largely reasonable. I would consider removing the SHOULD = for RSA for > PASSporT signatures, for two reasons: >=20 > 1. There's no legacy to deal with > 2. Because these objects are just sent out with no negotiation, it's = not that useful > to know that relying parties might or might not support your = algorithm. The safe > thing to do would be ECDSA. >=20 > I would also note that the above doesn't specify a curve, but I assume = we're talking > P-256. >=20 > -Ekr >=20 >=20 > On Mon, May 9, 2016 at 1:37 PM, Russ Housley = wrote: > I would rather be a bit more granular. >=20 > MUST support ECDSA for PASSporT signatures > SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures >=20 > and >=20 > MUST support ECDSA for certificate signatures > MUST support RSA PKCS#1 v1.5 for certificate signatures >=20 > Then, we should say something to product planners that at some point = in the future, we expect support for RSA to be downgraded. >=20 > Russ --Apple-Mail=_6ADA6AA5-3243-40C0-85A6-6DA3B71DCDFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Eric:

I was thinking P-256, but I = could be talked into:

MUST = support P-256
SHOULD support = P-384

Russ


On May 15, 2016, at 11:36 AM, Eric Rescorla <ekr@rtfm.com> wrote:

This seems largely reasonable. I would consider removing the = SHOULD for RSA for
PASSporT signatures, for two = reasons:

1. There's no legacy to deal = with
2. Because these objects are just sent out with no = negotiation, it's not that useful
to know that relying parties = might or might not support your algorithm. The safe
thing to = do would be ECDSA.

I would also note that the = above doesn't specify a curve, but I assume we're = talking
P-256.

-Ekr


On Mon, = May 9, 2016 at 1:37 PM, Russ Housley <housley@vigilsec.com> = wrote:
I would rather be a bit more granular.

        MUST support ECDSA for PASSporT = signatures
        SHOULD support RSA PKCS#1 v1.5 for PASSporT = signatures

and

        MUST support ECDSA for certificate = signatures
        MUST support RSA PKCS#1 v1.5 for certificate = signatures

Then, we should say something to product planners that at some point in = the future, we expect support for RSA to be downgraded.

Russ
=

= --Apple-Mail=_6ADA6AA5-3243-40C0-85A6-6DA3B71DCDFD-- From nobody Mon May 16 20:31:38 2016 Return-Path: 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 4975012D70F for ; Mon, 16 May 2016 20:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 x0ziWJ4jyC2M for ; Mon, 16 May 2016 20:31:35 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1738F12D591 for ; Mon, 16 May 2016 20:31:35 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id j74so3690658ywg.1 for ; Mon, 16 May 2016 20:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7gyQOt7p1vak3WfMLuE8xCSqHUwQIS9QdfGy70g59cA=; b=Mfjn6ZMqsrSvctAj28VnjIMKCi2BNmRg2FAPDTbuZ6FYVhCVeKVlVc9r+wLV74fX6g hhcGpCo9+qklVzlDgqPsc96dB9cKBB/G7Qaf1fxrDYUyMUltlPk0QRSaa2mZzk9MNSSR ta1LAD1YQgeBK+tUv7Sq6OmMuN+GkyoN9CpBxuvAvgliKxoqZYdkdy7TVYHsQAE9QXii /rTksUN6DYruC980caJ3Pw8ADK8yfJvr1nkby9QJj3zJPyDRQ8tExeKvlJi+0Nxgkjwe ZO3522yv2achykQUgStgxvg0SCOUsiCb637JabOn4RZfVEHMxcIzKDa/Hg+YerX2PSCn kbcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7gyQOt7p1vak3WfMLuE8xCSqHUwQIS9QdfGy70g59cA=; b=O5aYvI7tB3z7N81HGIQUV9dZ9dS/vY4HhdlAyWASH4wDh7hW0rBRdNMiomWwdVtfsR Txua/8yRvDkdojJJ/hM11HivkooyFK3bo9nN3cuamJr6qFzPYZXeKNE9f3YbjJWnCbNS uK5/CifZnAO8PerPtTO5KMgdlnlnDX8sIdW7P//mE0lrSqE7igzYtKNjG8Z/P4JBu5oF FF+V303UHrL+zafMFjZ+etXP79+DJZrsgifO+Du9m2IUNoJOCPqNLf5MePjGFHVunXdI KRr4Q9F95cUGaXSii4DWt8GrDL0w3/mJ+oJQYdvh26a7lIZDflQ2ucN8fUsrQBDMSbBA 5lrQ== X-Gm-Message-State: AOPr4FXCdPjSFlLu1vL9qvRkXyMgdcyMN45QRI2WOZ2Ij8Lhs8XvhFEpNiece61EfG0WTj9ZDGMxey6gqcDPRg== X-Received: by 10.129.164.145 with SMTP id b139mr11313894ywh.171.1463455894405; Mon, 16 May 2016 20:31:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Mon, 16 May 2016 20:30:54 -0700 (PDT) In-Reply-To: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> From: Eric Rescorla Date: Mon, 16 May 2016 23:30:54 -0400 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=94eb2c128ec2bb343c053301601b Archived-At: Cc: IETF STIR Mail List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 03:31:37 -0000 --94eb2c128ec2bb343c053301601b Content-Type: text/plain; charset=UTF-8 On Mon, May 16, 2016 at 5:01 PM, Russ Housley wrote: > Eric: > > I was thinking P-256, but I could be talked into: > > MUST support P-256 > SHOULD support P-384 > I would tend to just think MUST p-256. Less is more -Ekr > > Russ > > > On May 15, 2016, at 11:36 AM, Eric Rescorla wrote: > > This seems largely reasonable. I would consider removing the SHOULD for > RSA for > PASSporT signatures, for two reasons: > > 1. There's no legacy to deal with > 2. Because these objects are just sent out with no negotiation, it's not > that useful > to know that relying parties might or might not support your algorithm. > The safe > thing to do would be ECDSA. > > I would also note that the above doesn't specify a curve, but I assume > we're talking > P-256. > > -Ekr > > > On Mon, May 9, 2016 at 1:37 PM, Russ Housley wrote: > >> I would rather be a bit more granular. >> >> MUST support ECDSA for PASSporT signatures >> SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures >> >> and >> >> MUST support ECDSA for certificate signatures >> MUST support RSA PKCS#1 v1.5 for certificate signatures >> >> Then, we should say something to product planners that at some point in >> the future, we expect support for RSA to be downgraded. >> >> Russ >> > > --94eb2c128ec2bb343c053301601b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, May 16, 2016 at 5:01 PM, Russ Housley <housley@vigilsec.com= > wrote:
Eric:

I was thinking P-256, but I could be= talked into:

MUST support P-256
= SHOULD support P-384

I = would tend to just think MUST p-256. Less is more

= -Ekr
=C2=A0

=
Russ

On May 15, 2016, at 11:36 AM, Eric Rescorla <ekr@rtfm.com> wrote:

This seems largely reasonable. I wou= ld consider removing the SHOULD for RSA for
PASSporT signatures, for tw= o reasons:

1. There's no legacy to deal with
2. Because these objects are just sent out with no negotiation, it= 's not that useful
to know that relying parties might or migh= t not support your algorithm. The safe
thing to do would be ECDSA= .

I would also note that the above doesn't spe= cify a curve, but I assume we're talking
P-256.
-Ekr


<= div class=3D"gmail_quote">On Mon, May 9, 2016 at 1:37 PM, Russ Housley <housley@vigilsec.com> wrote:
I would rat= her be a bit more granular.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST support ECDSA for PASSporT signatures
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SHOULD support RSA PKCS#1 v1.5 for PASSporT sig= natures

and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST support ECDSA for certificate signatures =C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST support RSA PKCS#1 v1.5 for certificate si= gnatures

Then, we should say something to product planners that at some point in the= future, we expect support for RSA to be downgraded.

Russ

=

--94eb2c128ec2bb343c053301601b-- From nobody Mon May 16 20:51:21 2016 Return-Path: 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 CFEFA12D0E3 for ; Mon, 16 May 2016 20:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 59fL9w_HUjEl for ; Mon, 16 May 2016 20:51:18 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 4339D12B060 for ; Mon, 16 May 2016 20:51:18 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u4H3hmkp007049; Mon, 16 May 2016 23:51:17 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 22yrwusfc0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 May 2016 23:51:16 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u4H3pGJH022064; Mon, 16 May 2016 23:51:16 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u4H3p9QS022026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 May 2016 23:51:12 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 17 May 2016 03:50:59 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.208]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0294.000; Mon, 16 May 2016 23:50:59 -0400 From: "DOLLY, MARTIN C" To: Eric Rescorla Thread-Topic: [stir] Choice of STIR signature algorithm Thread-Index: AQHRrr+9OheKJ/Ct+Eel6HT7NDwuNJ+8UeSAgABsswD//8KPHA== Date: Tue, 17 May 2016 03:50:59 +0000 Message-ID: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D07F290CCF3B4462945FDD45AC278847attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-17_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy 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-1604210000 definitions=main-1605170046 Archived-At: Cc: IETF STIR Mail List , Russ Housley 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 03:51:20 -0000 --_000_D07F290CCF3B4462945FDD45AC278847attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric Why less is more? If we are not forward thinking (directionally), it will make it harder to t= ake the next step Thanks Martin C Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: 609-903-3360 Email: md3135@att.com On May 16, 2016, at 11:31 PM, Eric Rescorla > wrote: On Mon, May 16, 2016 at 5:01 PM, Russ Housley > wrote: Eric: I was thinking P-256, but I could be talked into: MUST support P-256 SHOULD support P-384 I would tend to just think MUST p-256. Less is more -Ekr Russ On May 15, 2016, at 11:36 AM, Eric Rescorla > wrote: This seems largely reasonable. I would consider removing the SHOULD for RSA= for PASSporT signatures, for two reasons: 1. There's no legacy to deal with 2. Because these objects are just sent out with no negotiation, it's not th= at useful to know that relying parties might or might not support your algorithm. The= safe thing to do would be ECDSA. I would also note that the above doesn't specify a curve, but I assume we'r= e talking P-256. -Ekr On Mon, May 9, 2016 at 1:37 PM, Russ Housley > wrote: I would rather be a bit more granular. MUST support ECDSA for PASSporT signatures SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures and MUST support ECDSA for certificate signatures MUST support RSA PKCS#1 v1.5 for certificate signatures Then, we should say something to product planners that at some point in the= future, we expect support for RSA to be downgraded. Russ _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_D07F290CCF3B4462945FDD45AC278847attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Eric

Why less is more?

If we are not forward thinking (directionall= y), it will make it harder to take the next step

Thanks

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards 
AT&T
Cell: 609-903-3360

On May 16, 2016, at 11:31 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Mon, May 16, 2016 at 5:01 PM, Russ Housley <housley@vigil= sec.com> wrote:
Eric:

I was thinking P-256, but I could be talked into:

MUST support P-256
SHOULD support P-384

I would tend to just think MUST p-256. Less is more

-Ekr
 

Russ


On May 15, 2016, at 11:36 AM, Eric Rescorla <ekr@rtfm.com> wrote:

This seems largely reasonable. I would consider removing t= he SHOULD for RSA for
PASSporT signatures, for two reasons:

1. There's no legacy to deal with
2. Because these objects are just sent out with no negotiation, it's n= ot that useful
to know that relying parties might or might not support your algorithm= . The safe
thing to do would be ECDSA.

I would also note that the above doesn't specify a curve, but I assume= we're talking
P-256.

-Ekr


On Mon, May 9, 2016 at 1:37 PM, Russ Housley <housley@vigil= sec.com> wrote:
I would rather be a bit more granular.

        MUST support ECDSA for PASSporT signatures
        SHOULD support RSA PKCS#1 v1.5 for PASSporT sig= natures

and

        MUST support ECDSA for certificate signatures         MUST support RSA PKCS#1 v1.5 for certificate si= gnatures

Then, we should say something to product planners that at some point in the= future, we expect support for RSA to be downgraded.

Russ


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ie= tf.org/mailman/listinfo/stir
--_000_D07F290CCF3B4462945FDD45AC278847attcom_-- From nobody Wed May 18 14:59:30 2016 Return-Path: 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 C5E6812D777 for ; Wed, 18 May 2016 14:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 w_56ydRPxRW2 for ; Wed, 18 May 2016 14:59:27 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E573C12D51A for ; Wed, 18 May 2016 14:59:26 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g133so62498113ywb.2 for ; Wed, 18 May 2016 14:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/i6fs+ITKxe3SXS+5iLdIquavFVH9hZXg+o3Yhdg04k=; b=r+oAfiIjeMBfC23gton/MwcJsCpP20WQUOZYKns550Z9/+4kxUlZKOJ8VKM4orEleO WF7VZ94nZTNLsF383xSyC6nVGX1DAgaELXmCpHTI8W/nvzko8fOohKPVpUYISMhmTxVI 0qGjzLCMEnWEEh3/l6zlMia+ngeWExqGnB+fdXKoa85/EmV3oZLYFja+A6mjtzweGbK8 pTUpz5vQpxNYnTW4nmI03wUCP8loCQhjI+I0zgIqEA+utZNVaIgTofd5S/gkNVIxMHLd iwXcngpcCyYpclyQ35Q1z5A6TiMAEd6nMNNInstTwiWTymD0Z0C0BkBZ267Jo5jUg2uR KGhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/i6fs+ITKxe3SXS+5iLdIquavFVH9hZXg+o3Yhdg04k=; b=CpZXSXM+1Q+OM2rAWPiqjSbPqJ6FuqLMNT20TrS1JFBz/0ACfHlHSxvbboTQhJD6BX ipDeOWCMlsxwnhTBLHxTPLmNN1oBHjuZXWEs7UXvOAx8GncgjrZClFcsA+cN3PyEWb4j NjAINlDSzDWL28c7s/H81xEAZe6Mwq0Mzhjt6+6gpUYbHgSRqipQNeMHu7VIrjtvZOov FTq2LE3Vw0XGPovE8/7ZpWmmJIOhrteyEoqZQ6xd2IkFGd7r4RCyn7miIL9Nl6hySSNr gbxAd42tRvXyHjqiCsjqIiY5iffq7iE8BztyWwLOgbwd1h/+Da2CJun9TAjnGGxsRhBX QR0g== X-Gm-Message-State: AOPr4FVpcvC4dErRG2P0Z3cbROPxHQUwOJG+czIZxaI1KN+ldK2sBX3rEf7O7BR3zFKZYjJibPMQpvD9Qm52DA== X-Received: by 10.129.51.140 with SMTP id z134mr5195251ywz.322.1463608766138; Wed, 18 May 2016 14:59:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Wed, 18 May 2016 14:58:46 -0700 (PDT) In-Reply-To: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> From: Eric Rescorla Date: Wed, 18 May 2016 14:58:46 -0700 Message-ID: To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=001a1140746e98d97f053324f8a6 Archived-At: Cc: IETF STIR Mail List , Russ Housley 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 21:59:29 -0000 --001a1140746e98d97f053324f8a6 Content-Type: text/plain; charset=UTF-8 Why would P-384 be a logical next step? On Mon, May 16, 2016 at 8:50 PM, DOLLY, MARTIN C wrote: > Eric > > Why less is more? > > If we are not forward thinking (directionally), it will make it harder to > take the next step > > Thanks > > Martin C Dolly > Lead Member of Technical Staff > Core & Government/Regulatory Standards > AT&T > Cell: 609-903-3360 > Email: md3135@att.com > > On May 16, 2016, at 11:31 PM, Eric Rescorla wrote: > > > On Mon, May 16, 2016 at 5:01 PM, Russ Housley > wrote: > >> Eric: >> >> I was thinking P-256, but I could be talked into: >> >> MUST support P-256 >> SHOULD support P-384 >> > > I would tend to just think MUST p-256. Less is more > > -Ekr > > >> >> Russ >> >> >> On May 15, 2016, at 11:36 AM, Eric Rescorla wrote: >> >> This seems largely reasonable. I would consider removing the SHOULD for >> RSA for >> PASSporT signatures, for two reasons: >> >> 1. There's no legacy to deal with >> 2. Because these objects are just sent out with no negotiation, it's not >> that useful >> to know that relying parties might or might not support your algorithm. >> The safe >> thing to do would be ECDSA. >> >> I would also note that the above doesn't specify a curve, but I assume >> we're talking >> P-256. >> >> -Ekr >> >> >> On Mon, May 9, 2016 at 1:37 PM, Russ Housley >> wrote: >> >>> I would rather be a bit more granular. >>> >>> MUST support ECDSA for PASSporT signatures >>> SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures >>> >>> and >>> >>> MUST support ECDSA for certificate signatures >>> MUST support RSA PKCS#1 v1.5 for certificate signatures >>> >>> Then, we should say something to product planners that at some point in >>> the future, we expect support for RSA to be downgraded. >>> >>> Russ >>> >> >> > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > --001a1140746e98d97f053324f8a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Why would P-384 be a logical next step?

On Mon, May 16, 2016 at 8:50 PM,= DOLLY, MARTIN C <md3135@att.com> wrote:
Eric

Why less is more?

If we are not forward thinking (directionally), it will make it harder= to take the next step

Thanks

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=C2=A0
AT&T

On May 16, 2016, at 11:31 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Mon, May 16, 2016 at 5:01 PM, Russ Housley <housley@vigil= sec.com> wrote:
Eric:

I was thinking P-256, but I could be talked into:

MUST support P-256
SHOULD support P-384

I would tend to just think MUST p-256. Less is more

-Ekr
=C2=A0

Russ


On May 15, 2016, at 11:36 AM, Eric Rescorla <ekr@rtfm.com> wrote:

This seems largely reasonable. I would consider removing t= he SHOULD for RSA for
PASSporT signatures, for two reasons:

1. There's no legacy to deal with
2. Because these objects are just sent out with no negotiation, it'= ;s not that useful
to know that relying parties might or might not support your algorithm= . The safe
thing to do would be ECDSA.

I would also note that the above doesn't specify a curve, but I as= sume we're talking
P-256.

-Ekr


On Mon, May 9, 2016 at 1:37 PM, Russ Housley <housley@vigil= sec.com> wrote:
I would rather be a bit more granular.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST support ECDSA for PASSporT signatures
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SHOULD support RSA PKCS#1 v1.5 for PASSporT sig= natures

and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST support ECDSA for certificate signatures =C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST support RSA PKCS#1 v1.5 for certificate si= gnatures

Then, we should say something to product planners that at some point in the= future, we expect support for RSA to be downgraded.

Russ


_______________________________________________
stir mailing list
stir@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/stir

--001a1140746e98d97f053324f8a6-- From nobody Thu May 19 05:09:14 2016 Return-Path: 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 6C4B912DA18 for ; Thu, 19 May 2016 05:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com 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 Qqcp5I_34U12 for ; Thu, 19 May 2016 05:09:11 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC95B12D83B for ; Thu, 19 May 2016 05:09:10 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id n62so41017290qkc.2 for ; Thu, 19 May 2016 05:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=0zF+WEFlzzyAr6C+vITBAXeLeshS0jRSJiGNmZvfIpE=; b=TLTiERRwLHzkNDY1As51G0Z6krDRz2b+J4HUZLpb0Hooqhh4Az3/3cH7SmYzzMeS0f Bdxa2f58Yq2UhHmZUl7pp00Uk3LJgOhBw70JygOZmTxYoML3851pqWhy0QnOVOnAYBP+ D74trBnhVB9adU+fb6OWaoj5MMlAChZ0T6OPXE3YIdOAxD4/ajNZOEJK7xMknl3SQ4RS 2ekDoqynoV+1MaTX/mTVY/N5zj3gsbPl++SGFpCEb3pgZtnLplVsvU+U2t9ZyEUgfYEg q5nVZ34Cj87RgZ/1rQ4lq9zCGTm+kduBiGaSc8bAbWjCyxq+OwGWGftWAFf6Wx2ev7PS 2bIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=0zF+WEFlzzyAr6C+vITBAXeLeshS0jRSJiGNmZvfIpE=; b=Yvo7gFDs+vXD86jHhzoFABi18lKW6k0by6/6OtkfSNVJdQ/FVLHw7G9ZilzNXyommf VnHSA8C0sw+LZevWSqdAVrtsJ9ezs8IyecSypaK3/HOwjjbGVXNyONBUyttciqSz30Jj jsr0KcZW6qOoOsTUY20nFFzGFONOzRfXUZ2wqBv1/1aRoEATmyKFB7kfe8wUVgJmJo+t gTG1lqSwU0Fs5XrtykDa+nli4WSkI0PPqVwgywVV0OKa0o9E5RRZ8je6bm9UZe6H98Uq vi60gT8rkAalFfYVjwkrVW2QUiQkpYPFt4VVJ90i2S66oTy4CXCX+IokLIJfSA+OGOnx 3geQ== X-Gm-Message-State: AOPr4FX3cokF0QSj+xwf6PyPuv5bh5TGQfkZiAns+VOAbz8RrfnRpwrC3m6iDxJF8xAVxw== X-Received: by 10.55.134.6 with SMTP id i6mr14005418qkd.185.1463659749862; Thu, 19 May 2016 05:09:09 -0700 (PDT) Received: from [10.199.13.80] ([65.114.164.3]) by smtp.gmail.com with ESMTPSA id t65sm6459329qhe.0.2016.05.19.05.09.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 May 2016 05:09:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D9D6B5A1-15EE-4B64-894A-61FBEAAA2DB2" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: Date: Thu, 19 May 2016 08:09:08 -0400 Message-Id: <2CBBA546-1DBF-40D7-80E8-0AAD93A2682C@chriswendt.net> References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF STIR Mail List , Russ Housley 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 12:09:12 -0000 --Apple-Mail=_D9D6B5A1-15EE-4B64-894A-61FBEAAA2DB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>=20 >> I would also note that the above doesn't specify a curve, but I = assume we're talking >> P-256. Yes: https://tools.ietf.org/html/rfc7518#section-3.1 = --Apple-Mail=_D9D6B5A1-15EE-4B64-894A-61FBEAAA2DB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


I would also note that the above = doesn't specify a curve, but I assume we're talking
P-256.

Yes:

https://tools.ietf.org/html/rfc7518#section-3.1


= --Apple-Mail=_D9D6B5A1-15EE-4B64-894A-61FBEAAA2DB2-- From nobody Thu May 19 05:12:00 2016 Return-Path: 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 EBFA212B030 for ; Thu, 19 May 2016 05:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com 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 B1QvJYjGpiiu for ; Thu, 19 May 2016 05:11:57 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4683E12B004 for ; Thu, 19 May 2016 05:11:57 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id a75so11240364qge.2 for ; Thu, 19 May 2016 05:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ogev56PXKrHv7nSfMWVIjNJ3wqwoA5o/fbFIj2TcI38=; b=sH5KdahkdIp1Ar7gyaR7h+IWVJNZWz00EpJ9RAuE13qMQj5Zy7QZ/aSO/09FZcYnbg SMkqs2Jkp95U7/tCTw+Ps6kEWwsd7OdsUDFcUBvrDZAFA6Fz32R326s55Q8MtJFMhF/s nIkOBSJyY6crJtUkLQGAJc4LyF4mmenbbguannnzJOTcC2lcnAcj0Jl6waa5qGfDMy5x iqmkngEE+uXUaZqvLKxI5z4v0FGSPlZ1ZfBjKHNGb5lX/7mz7/ooy3iIwt4c+evkZWDw 6eRjz9zJRba/5N+37/eKRFgQaxPIq2EtWZtSL7sxqRqR7oH/7oErQYbYzPCZ93DN8JBs +5FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ogev56PXKrHv7nSfMWVIjNJ3wqwoA5o/fbFIj2TcI38=; b=AJuyBkC4yp2ByGvtUqj7HNwvgi/L0iX8O9+T1S97MFnz81Pl3XGqtQcGqXNKyxhvls Jy5MRGu+qyVbuGKxB4TpLEIcKBpTG0ESnJmr8nhfQxQWJ6vQQi4EAI+7Z9+Yxp9uqXQ+ vVcS/ksqYWJC07KFfdA/LMO0Rxxg85zhyck60XZ2/BJf/eYnkh5uAuccTHvpOpdy704z DA1VERrkiHEI20gDVB6XDyUa8kL5w1Y7p/duv8ve/xbGPZOrXICXRM+oJLb0R4SHQ8xj 2VI9SbxiziBPcSgkQS+rjzCvx/4xoH+rgXzEF8gXdy1SezdFYhmHjpotiqQhhv6uBsSB 2kPQ== X-Gm-Message-State: AOPr4FWfW70+B+NXo6kQcWgL9OteY+nQ+vtWfuyLbwVvGP60rWwxDvr4yW1AYX/Ky42YvA== X-Received: by 10.140.145.82 with SMTP id 79mr13765411qhr.95.1463659916453; Thu, 19 May 2016 05:11:56 -0700 (PDT) Received: from [10.199.13.80] ([65.114.164.3]) by smtp.gmail.com with ESMTPSA id d6sm6467310qke.40.2016.05.19.05.11.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 May 2016 05:11:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A7FB05BB-56D5-4705-921A-38E383DD304E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: Date: Thu, 19 May 2016 08:11:54 -0400 Message-Id: <43E97208-EBA0-4DE6-8CB7-E9AAFD212A3B@chriswendt.net> References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF STIR Mail List , Russ Housley 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 12:11:59 -0000 --Apple-Mail=_A7FB05BB-56D5-4705-921A-38E383DD304E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Whenever we say SHOULD i believe this is in the context of the = authentication service only, because this would imply a MUST on the = verification side, right? So, should we go there or just stick with MUST on > On May 16, 2016, at 11:30 PM, Eric Rescorla wrote: >=20 >=20 > On Mon, May 16, 2016 at 5:01 PM, Russ Housley > wrote: > Eric: >=20 > I was thinking P-256, but I could be talked into: >=20 > MUST support P-256 > SHOULD support P-384 >=20 > I would tend to just think MUST p-256. Less is more >=20 > -Ekr > =20 >=20 > Russ >=20 >=20 > On May 15, 2016, at 11:36 AM, Eric Rescorla > wrote: >=20 >> This seems largely reasonable. I would consider removing the SHOULD = for RSA for >> PASSporT signatures, for two reasons: >>=20 >> 1. There's no legacy to deal with >> 2. Because these objects are just sent out with no negotiation, it's = not that useful >> to know that relying parties might or might not support your = algorithm. The safe >> thing to do would be ECDSA. >>=20 >> I would also note that the above doesn't specify a curve, but I = assume we're talking >> P-256. >>=20 >> -Ekr >>=20 >>=20 >> On Mon, May 9, 2016 at 1:37 PM, Russ Housley > wrote: >> I would rather be a bit more granular. >>=20 >> MUST support ECDSA for PASSporT signatures >> SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures >>=20 >> and >>=20 >> MUST support ECDSA for certificate signatures >> MUST support RSA PKCS#1 v1.5 for certificate signatures >>=20 >> Then, we should say something to product planners that at some point = in the future, we expect support for RSA to be downgraded. >>=20 >> Russ >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_A7FB05BB-56D5-4705-921A-38E383DD304E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Whenever we say SHOULD i believe this is in the context of = the authentication service only, because this would imply a MUST on the = verification side, right?

So, should we go there or just stick with MUST on

On May 16, 2016, at 11:30 PM, Eric Rescorla <ekr@rtfm.com> = wrote:


On Mon, May 16, 2016 at 5:01 PM, Russ Housley = <housley@vigilsec.com> = wrote:
Eric:

I was thinking P-256, but I could be = talked into:

= MUST support P-256
SHOULD support = P-384

I would tend to just think MUST p-256. Less is more

-Ekr
 

Russ


On May 15, 2016, at 11:36 AM, Eric Rescorla <ekr@rtfm.com> wrote:

This seems largely = reasonable. I would consider removing the SHOULD for RSA for
PASSporT signatures, for two reasons:

1. There's no legacy to deal = with
2. Because these objects are just sent out = with no negotiation, it's not that useful
to know = that relying parties might or might not support your algorithm. The = safe
thing to do would be ECDSA.

I would also note that = the above doesn't specify a curve, but I assume we're talking
P-256.

-Ekr


On Mon, = May 9, 2016 at 1:37 PM, Russ Housley <housley@vigilsec.com> wrote:
I would rather be a bit more granular.

        MUST support ECDSA for PASSporT = signatures
        SHOULD support RSA PKCS#1 v1.5 for PASSporT = signatures

and

        MUST support ECDSA for certificate = signatures
        MUST support RSA PKCS#1 v1.5 for certificate = signatures

Then, we should say something to product planners that at some point in = the future, we expect support for RSA to be downgraded.

Russ


_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_A7FB05BB-56D5-4705-921A-38E383DD304E-- From nobody Tue May 24 14:41:19 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 704EF12D557; Tue, 24 May 2016 14:41:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160524214118.14096.34219.idtracker@ietfa.amsl.com> Date: Tue, 24 May 2016 14:41:18 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-passport-02.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 21:41:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Persona Assertion Token Authors : Chris Wendt Jon Peterson Filename : draft-ietf-stir-passport-02.txt Pages : 21 Date : 2016-05-24 Abstract: This document defines a token format for verifying with non- repudiation the sender of and authorization to send information related to the originator of personal communications. A cryptographic signature is defined to protect the integrity of the information used to identify the originator of a personal communications session (e.g. the telephone number or URI) and verify the accuracy of this information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an unsecure channel. The Persona Assertion Token (PASSporT) is particularly useful for many personal communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-passport-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 25 08:09:06 2016 Return-Path: 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 33BDA12D7CB for ; Wed, 25 May 2016 08:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 MsOJGEEr688O for ; Wed, 25 May 2016 08:09:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720B412D7DC for ; Wed, 25 May 2016 08:07:32 -0700 (PDT) Received: from unnumerable.local ([108.19.241.180]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4PF7UZB071812 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 25 May 2016 10:07:32 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [108.19.241.180] claimed to be unnumerable.local References: <20160428164222.5530.69828.idtracker@ietfa.amsl.com> To: stir@ietf.org From: Robert Sparks X-Forwarded-Message-Id: <20160428164222.5530.69828.idtracker@ietfa.amsl.com> Message-ID: Date: Wed, 25 May 2016 10:07:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160428164222.5530.69828.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------27D2405BF42DD033E7986745" Archived-At: Subject: [stir] Reminder: STIR WG Virtual Interim Meeting: May 27, 2016 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:09:05 -0000 This is a multi-part message in MIME format. --------------27D2405BF42DD033E7986745 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Our interim call is this Friday. I expect to focus primarily on the three drafts called out below. Additionally, if you have not already read https://datatracker.ietf.org/doc/draft-jennings-stir-rtcweb-identity/ please do so before the call. There are some questions and suggestions, particularly in section 3, that we are likely to discuss as part of talking about the three drafts below. RjS -------- Forwarded Message -------- Subject: [stir] STIR WG Virtual Interim Meeting: May 27, 2016 Date: Thu, 28 Apr 2016 09:42:22 -0700 From: IESG Secretary Reply-To: ietf@ietf.org To: IETF Announcement List CC: stir@ietf.org The Secure Telephone Identity Revisited (STIR) WG will hold a virtual interim meeting on May 27th at 10am Pacific US/ 1pm Eastern US/ 1700 UTC for two hours. Call in details are available on the STIR WG list here: The interim will focus on finishing the group's work on these three drafts: Please watch the STIR list for finer agenda detail. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --------------27D2405BF42DD033E7986745 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Our interim call is this Friday.

I expect to focus primarily on the three drafts called out below.

Additionally, if you have not already read

https://datatracker.ietf.org/doc/draft-jennings-stir-rtcweb-identity/

please do so before the call. There are some questions and suggestions, particularly in section 3, that we are likely to discuss as part of talking about the three drafts below.

RjS


-------- Forwarded Message --------
Subject: [stir] STIR WG Virtual Interim Meeting: May 27, 2016
Date: Thu, 28 Apr 2016 09:42:22 -0700
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: ietf@ietf.org
To: IETF Announcement List <ietf-announce@ietf.org>
CC: stir@ietf.org 


The Secure Telephone Identity Revisited (STIR) WG will hold a virtual 
interim meeting on May 27th at 10am Pacific US/ 1pm Eastern US/ 1700 UTC 
for two hours.

Call in details are available on the STIR WG list here:
<http://mailarchive.ietf.org/arch/msg/stir/KiRbsF4XoJVsLP4LwAE1RHV4qkc>

The interim will focus on finishing the group's work on these three 
drafts:
<https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/>
<https://datatracker.ietf.org/doc/draft-ietf-stir-passport/>
<https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/>

Please watch the STIR list for finer agenda detail.

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir
--------------27D2405BF42DD033E7986745-- From nobody Wed May 25 10:29:33 2016 Return-Path: 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 B5D5A12D896 for ; Wed, 25 May 2016 10:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com 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 b0KP0vD0_q_u for ; Wed, 25 May 2016 10:29:30 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A8712D893 for ; Wed, 25 May 2016 10:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type; bh=dcOZZ+08u7yy6dTLXHSS+BrrXyNYrETIo22+dV6M8kc=; b=deRIROwe21E6u4Cw7vY5eLiGmf aZdBmpm1oFyYiqLjB22MbqaFwj5+ufcJmIZzKvJyXGO6/0aQGBYjGvFD0YDBeHWthQVOJm3zPT9/t 9WjiWNrjT7NbIZX27w56MN3QPYpb0NmLGmr0uvMdFDgooCEgfnQT2bPlaMZLpCyS0iyc=; Received: from [147.226.77.146] (port=60834 helo=[10.223.107.137]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b5ccX-00067Z-8H for stir@ietf.org; Wed, 25 May 2016 10:29:29 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_3302A81A-92D0-4B8F-A196-640CBE282884"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: <43E97208-EBA0-4DE6-8CB7-E9AAFD212A3B@chriswendt.net> Date: Wed, 25 May 2016 13:29:23 -0400 Message-Id: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> <43E97208-EBA0-4DE6-8CB7-E9AAFD212A3B@chriswendt.net> To: IETF STIR Mail List X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 17:29:32 -0000 --Apple-Mail=_3302A81A-92D0-4B8F-A196-640CBE282884 Content-Type: multipart/alternative; boundary="Apple-Mail=_9285F249-031C-4EF2-8831-F859ECBE41C4" --Apple-Mail=_9285F249-031C-4EF2-8831-F859ECBE41C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And Eric=E2=80=99s [B=E2=80=99s] Law=E2=84=A2 holds: Every SHOULD MUST = have an UNLESS. Otherwise, the SHOULD is really a MAY which is really = useless in a protocol specification. > On May 19, 2016, at 8:11 AM, Chris Wendt = wrote: >=20 > Whenever we say SHOULD i believe this is in the context of the = authentication service only, because this would imply a MUST on the = verification side, right? >=20 > So, should we go there or just stick with MUST on >=20 >> On May 16, 2016, at 11:30 PM, Eric Rescorla > wrote: >>=20 >>=20 >> On Mon, May 16, 2016 at 5:01 PM, Russ Housley > wrote: >> Eric: >>=20 >> I was thinking P-256, but I could be talked into: >>=20 >> MUST support P-256 >> SHOULD support P-384 >>=20 >> I would tend to just think MUST p-256. Less is more >>=20 >> -Ekr >>=20 >>=20 >> Russ >>=20 >>=20 >> On May 15, 2016, at 11:36 AM, Eric Rescorla > wrote: >>=20 >>> This seems largely reasonable. I would consider removing the SHOULD = for RSA for >>> PASSporT signatures, for two reasons: >>>=20 >>> 1. There's no legacy to deal with >>> 2. Because these objects are just sent out with no negotiation, it's = not that useful >>> to know that relying parties might or might not support your = algorithm. The safe >>> thing to do would be ECDSA. >>>=20 >>> I would also note that the above doesn't specify a curve, but I = assume we're talking >>> P-256. >>>=20 >>> -Ekr >>>=20 >>>=20 >>> On Mon, May 9, 2016 at 1:37 PM, Russ Housley > wrote: >>> I would rather be a bit more granular. >>>=20 >>> MUST support ECDSA for PASSporT signatures >>> SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures >>>=20 >>> and >>>=20 >>> MUST support ECDSA for certificate signatures >>> MUST support RSA PKCS#1 v1.5 for certificate signatures >>>=20 >>> Then, we should say something to product planners that at some point = in the future, we expect support for RSA to be downgraded. >>>=20 >>> Russ >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_9285F249-031C-4EF2-8831-F859ECBE41C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 And Eric=E2=80=99s [B=E2=80=99s] Law=E2=84=A2 holds: Every = SHOULD MUST have an UNLESS. Otherwise, the SHOULD = is really a MAY which is really useless in a protocol specification.

On May 19, 2016, at 8:11 AM, Chris Wendt <chris-ietf@chriswendt.net> wrote:

Whenever we = say SHOULD i believe this is in the context of the authentication = service only, because this would imply a MUST on the verification side, = right?

So, should we = go there or just stick with MUST on

On May 16, 2016, at 11:30 PM, Eric Rescorla <ekr@rtfm.com> = wrote:


On Mon, May 16, 2016 at 5:01 PM, Russ Housley = <housley@vigilsec.com> = wrote:
Eric:

I was thinking P-256, but I could be = talked into:

= MUST support P-256
SHOULD support = P-384

I would tend to just think MUST p-256. Less is more

-Ekr
 

Russ


On May 15, 2016, at 11:36 AM, Eric Rescorla <ekr@rtfm.com> wrote:

This seems largely = reasonable. I would consider removing the SHOULD for RSA for
PASSporT signatures, for two reasons:

1. There's no legacy to deal = with
2. Because these objects are just sent out = with no negotiation, it's not that useful
to know = that relying parties might or might not support your algorithm. The = safe
thing to do would be ECDSA.

I would also note that = the above doesn't specify a curve, but I assume we're talking
P-256.

-Ekr


On Mon, = May 9, 2016 at 1:37 PM, Russ Housley <housley@vigilsec.com> wrote:
I would rather be a bit more granular.

        MUST support ECDSA for PASSporT = signatures
        SHOULD support RSA PKCS#1 v1.5 for PASSporT = signatures

and

        MUST support ECDSA for certificate = signatures
        MUST support RSA PKCS#1 v1.5 for certificate = signatures

Then, we should say something to product planners that at some point in = the future, we expect support for RSA to be downgraded.

Russ


_______________________________________________
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

= --Apple-Mail=_9285F249-031C-4EF2-8831-F859ECBE41C4-- --Apple-Mail=_3302A81A-92D0-4B8F-A196-640CBE282884 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXReDzAAoJEORoZaSQsc1IdXQQAOZfGnCrbMUpSwBmHLSz/c3V OvT2BP13Gk1yoknfDXu62YIvjEtWL+mdw4XN9NmwrP3K0DyuFvJelQ0gRVAncMqL pbNQQH6wKeKF8tEKv8oxksZamKfWtjVXwsWeNxMpbqB0Q2mcoED6hmHLKZb6UQuF e3uOFtV9GX0NgJ8NKxATFxsTTAAj5vOw0aKdkxD0oe1y27Cy+LdjTC81AohP3lDh xPrADpmTIIyRmst7vdrBG3s/HZsjUDm20QH5OsHmLbfZGkEzIQeT/u8fPF9EM+gl T8LL10GjVc8QWjf8LEu+oM7fU1vMpSLclzue15uuGXWSDZ7c1r8H7VF/3CtA9Q1G FrKv8A1EbJU4eyfTQ+NeDVIDxHMFf1zXPvOSwkNn9MVWgkzNwuMQK2N1j2ADXqVv +9TsIRT60wJehzLQt/fZy1M8Pf6npRVvtBXlRLLwjfqN6ETaQbmJwhDRbVUAm502 k8i/m9KglwRrn4/TKteWvNTuaGE03AyPlyCP9s5nyomTQ+r6twoXsz2z9Ju1OYmf T7sKYG5KmcPNc630UXCvD55hcjUGget2uRCWnbENlqJAmYg65Tu0DJReCinX9EUf i9LruQ60dfbK0u9KiLiTy/zMjiwWpZiIk0NrrML2T1r/Pj/YC58ctJe3T8f9Sx4z rmfpoYB7JWWW19gmbJf8 =Md54 -----END PGP SIGNATURE----- --Apple-Mail=_3302A81A-92D0-4B8F-A196-640CBE282884-- From nobody Wed May 25 12:42:09 2016 Return-Path: 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 3100512DC1D for ; Wed, 25 May 2016 12:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 V5MwEgbZ3ev6 for ; Wed, 25 May 2016 12:42:07 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id BCD5F12DCEB for ; Wed, 25 May 2016 12:41:12 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id B82C5F240DC for ; Wed, 25 May 2016 15:41:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id vLdLM2uiohBU for ; Wed, 25 May 2016 15:23:29 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 5A402F240D9 for ; Wed, 25 May 2016 15:41:12 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_5145C337-286D-4E19-847A-216570C387AE" Message-Id: <789A387A-B0E2-4DF6-9807-55E0210AEEBD@vigilsec.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Wed, 25 May 2016 15:41:18 -0400 References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <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> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> <43E97208-EBA0-4DE6-8CB7-E9AAFD212A3B@chriswendt.net > To: IETF STIR Mail List In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 19:42:08 -0000 --Apple-Mail=_5145C337-286D-4E19-847A-216570C387AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is what I am hearing=85 MUST support ECDSA with P-256 for PASSporT signatures and MUST support ECDSA with P-256 for certificate signatures MUST support RSA PKCS#1 v1.5 for certificate signatures Then, we should say something to product planners that at some point in = the future, we expect support for RSA to be downgraded. Russ --Apple-Mail=_5145C337-286D-4E19-847A-216570C387AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
This is what I am = hearing=85

        = MUST support ECDSA with P-256 for PASSporT = signatures

and

  =       MUST support ECDSA with P-256 for certificate = signatures
        MUST support RSA PKCS#1 = v1.5 for certificate signatures

Then, we should = say something to product planners that at some point in the future, we = expect support for RSA to be = downgraded.

Russ

<= div class=3D"" style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space;">
= --Apple-Mail=_5145C337-286D-4E19-847A-216570C387AE-- From nobody Wed May 25 13:46:03 2016 Return-Path: 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 9D96F12DD38 for ; Wed, 25 May 2016 13:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 KrtAaOneE5G5 for ; Wed, 25 May 2016 13:46:00 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 C0B4D12DD5D for ; Wed, 25 May 2016 13:45:55 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by comcast with SMTP id 5fc2bgyIAnIc75fghb0Ff6; Wed, 25 May 2016 20:45:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464209155; bh=gZjoAu7bYgDCE/ko8fDr+8aQTchaT1U2Ojgzp5MamLQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=NjeDTL92hH2TA2MA9KLIG2jW1RPTO4v8m5b8mJ4dCPLicmoIOOBquQ1hnX6efOuGl OhIhRVEck+1VtQHYvcefB+4Cgz96dSyjAmEYhfDGOw+ICyWrgwdBlin+KMTJCDEpGV um5InsMTbn7U7YqsDdUwsUbqPCAGbm3M/4leKxND93ru1OknIHYX1eqeFx22VVicg8 POG5GJksD29+Z8bWIUx/N7I6th2hqITHyKCisc5UwUI1OkH3P+PUWujI7CvpOrMX7X PO2ksRXf543MImUeUkeEoA+ObZhZjoCpSttjNVdP3vkfXngS/AE4fOsY9sL/qX6oB9 b5+1DNQdZ5BMA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id yklu1s00T3KdFy101klubq; Wed, 25 May 2016 20:45:55 +0000 To: stir@ietf.org References: <20160524214118.14096.34219.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Wed, 25 May 2016 16:46:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160524214118.14096.34219.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-02.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 20:46:01 -0000 I looked at this version and found one language issue in Section 3.2.2.2: ... If there is multiple fingerprint values, more than one, the fingerprint values should be constructed ... The English text makes no sense. How about: ... If there are multiple fingerprint values they should be constructed ... Thanks, Paul On 5/24/16 5:41 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Telephone Identity Revisited of the IETF. > > Title : Persona Assertion Token > Authors : Chris Wendt > Jon Peterson > Filename : draft-ietf-stir-passport-02.txt > Pages : 21 > Date : 2016-05-24 > > Abstract: > This document defines a token format for verifying with non- > repudiation the sender of and authorization to send information > related to the originator of personal communications. A > cryptographic signature is defined to protect the integrity of the > information used to identify the originator of a personal > communications session (e.g. the telephone number or URI) and verify > the accuracy of this information at the destination. The > cryptographic signature is defined with the intention that it can > confidently verify the originating persona even when the signature is > sent to the destination party over an unsecure channel. The Persona > Assertion Token (PASSporT) is particularly useful for many personal > communications applications over IP networks and other multi-hop > interconnection scenarios where the originating and destination > parties may not have a direct trusted relationship. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-stir-passport-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From nobody Wed May 25 17:50:51 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E06E112D0D3; Wed, 25 May 2016 17:50:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160526005048.2945.60383.idtracker@ietfa.amsl.com> Date: Wed, 25 May 2016 17:50:48 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-rfc4474bis-09.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 00:50:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Authenticated Identity Management in the Session Initiation Protocol (SIP) Authors : Jon Peterson Cullen Jennings Eric Rescorla Chris Wendt Filename : draft-ietf-stir-rfc4474bis-09.txt Pages : 38 Date : 2016-05-25 Abstract: The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the signer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-rfc4474bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 25 18:04:32 2016 Return-Path: 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 39F2612D0FE for ; Wed, 25 May 2016 18:04:31 -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 ITxnz5cXHdhJ for ; Wed, 25 May 2016 18:04:29 -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 1626112D0D3 for ; Wed, 25 May 2016 18:04:29 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4Q148Er010052 for ; Wed, 25 May 2016 21:04:28 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 23442h03ng-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 25 May 2016 21:04:28 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Wed, 25 May 2016 21:04:27 -0400 From: "Peterson, Jon" To: "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-rfc4474bis-09.txt Thread-Index: AQHRtuioesAqFDOwFEO4hBYu91cTBJ/KNPuA Date: Thu, 26 May 2016 01:04:27 +0000 Message-ID: References: <20160526005048.2945.60383.idtracker@ietfa.amsl.com> In-Reply-To: <20160526005048.2945.60383.idtracker@ietfa.amsl.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.213] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-25_12:, , 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-1604210000 definitions=main-1605260010 Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-rfc4474bis-09.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 01:04:31 -0000 We will discuss this in more detail on Friday's interim call, but for those eager for an advance look at rfc4474bis-09, the interesting changes are as follows: Some text has been added to better explain verification service handling of multiple Identity headers, especially in failure cases. As a part of that, the response codes of RFC4474 have been amended slightly to take into account the potential for multiple Identity headers, as well as some prior changes to the protocol syntax (like Identity-Info being replaced with the "info" parameter of Identity). Much of that was overdue clean-up. The authentication service and verification service sections now both have specific text about how "canon" is sent and received, as well as some motivational text for "canon". Early implementer feedback suggested this was vague, hopefully it is more crisp now. The text about when and how verifiers can prefer "iat" in "canon" over the Date header has been beefed up as well. rfc4474bis now just points to PASSporT for the description of how "mky" is populated, as well as for all algorithms used internally within PASSporT to sign the headers and claims. For that reason, the algorithm registry defined by RFC4474 has now been deprecated. Certificate signing algorithms are out of scope of rfc4474bis, of course, and should instead appear in stir-certs. Also, the gatewaying section is gone - most of that conceptually resides in the PASSporT spec now. Jon Peterson Neustar, Inc. On 5/25/16, 5:50 PM, "stir on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Secure Telephone Identity Revisited of >the IETF. > > Title : Authenticated Identity Management in the >Session Initiation Protocol (SIP) > Authors : Jon Peterson > Cullen Jennings > Eric Rescorla > Chris Wendt > Filename : draft-ietf-stir-rfc4474bis-09.txt > Pages : 38 > Date : 2016-05-25 > >Abstract: > The baseline security mechanisms in the Session Initiation Protocol > (SIP) are inadequate for cryptographically assuring the identity of > the end users that originate SIP requests, especially in an > interdomain context. This document defines a mechanism for securely > identifying originators of SIP requests. It does so by defining a > SIP header field for conveying a signature used for validating the > identity, and for conveying a reference to the credentials of the > signer. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-09 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-rfc4474bis-09 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Thu May 26 17:51:52 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB89E12D9EE; Thu, 26 May 2016 17:51:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160527005150.14579.99232.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2016 17:51:50 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-certificates-04.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 00:51:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Secure Telephone Identity Credentials: Certificates Authors : Jon Peterson Sean Turner Filename : draft-ietf-stir-certificates-04.txt Pages : 19 Date : 2016-05-26 Abstract: In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically proves authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-certificates-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-certificates-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 26 17:54:40 2016 Return-Path: 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 C93E412D17D for ; Thu, 26 May 2016 17:54:38 -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 byLgBhlwTEtD for ; Thu, 26 May 2016 17:54:37 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 070FA12B050 for ; Thu, 26 May 2016 17:54:35 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u4R0rcQ8011238 for ; Thu, 26 May 2016 20:54:35 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 23442kftkr-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 26 May 2016 20:54:34 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 26 May 2016 20:54:33 -0400 From: "Peterson, Jon" To: "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-certificates-04.txt Thread-Index: AQHRt7H4gOEpBGZc7kiFEe99DT5yk5/LwvUA Date: Fri, 27 May 2016 00:54:32 +0000 Message-ID: References: <20160527005150.14579.99232.idtracker@ietfa.amsl.com> In-Reply-To: <20160527005150.14579.99232.idtracker@ietfa.amsl.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.213] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C64611895BE9E4A821318190D67CCD2@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-26_14:, , 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-1604210000 definitions=main-1605270008 Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-certificates-04.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 00:54:39 -0000 This is a small update of the stir-certs document, to reflect the consensus on algorithms that has been forged on the list here, and also to introduce a new "Certificate Usage" section that explicitly answers the requirements in rfc4474bis Section 6.4. Jon Peterson Neustar, Inc. On 5/26/16, 5:51 PM, "stir on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Secure Telephone Identity Revisited of >the IETF. > > Title : Secure Telephone Identity Credentials: >Certificates > Authors : Jon Peterson > Sean Turner > Filename : draft-ietf-stir-certificates-04.txt > Pages : 19 > Date : 2016-05-26 > >Abstract: > In order to prevent the impersonation of telephone numbers on the > Internet, some kind of credential system needs to exist that > cryptographically proves authority over telephone numbers. This > document describes the use of certificates in establishing authority > over telephone numbers, as a component of a broader architecture for > managing telephone numbers as identities in protocols like SIP. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-stir-certificates-04 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-certificates-04 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Fri May 27 08:21:45 2016 Return-Path: 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 6306712B018 for ; Fri, 27 May 2016 08:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9RC4nSu250oq for ; Fri, 27 May 2016 08:21:41 -0700 (PDT) Received: from mail.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id E4D6212D6A2 for ; Fri, 27 May 2016 08:21:40 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id D5E44F24096; Fri, 27 May 2016 11:21:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 5UK2yqS7y2WS; Fri, 27 May 2016 11:03:40 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 27C30F9C0FF; Fri, 27 May 2016 09:55:15 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 27 May 2016 09:55:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <875C575A-6AE6-4B9A-84D7-4E6FB266D30F@vigilsec.com> References: <20160526005048.2945.60383.idtracker@ietfa.amsl.com> To: Jon Peterson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] I-D Action: draft-ietf-stir-rfc4474bis-09.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 15:21:43 -0000 Jon: Thanks for posting the update. I think the document is ready for WG Last Call. That said, I do have = two fairly minor comments: In Section 4, the 4th paragraph talks about "JSON representations of = headers and claims which mirror certain parts of the SIP request.=94 = Then, the PASSporT object includes a signature over these JSON = representations. In the next paragraph, we find out that the =93cannon=94= parameter can carry some JSON. I think we need to be clear that the = =93canon=94 must contain exactly the same JSON representations of = headers and claims as were signed. The =93canon=94 parameter does not = solve anything if they can be different in any way. Also, you may want = to say something about base64 encoding here. Section 5.2.1 says that =93canon=94 is provided "purely as an = optimization and debugging mechanism for the verification service.=94 I = thought we talked about some cases where it is needed to make things = work. I think the reason for the MAY in the second paragraph of this = section is to allow those cases to work properly. I=92m not suggestion = that those cases be included here, but maybe this statement should be = dropped. Russ On May 25, 2016, at 9:04 PM, Peterson, Jon = wrote: >=20 > We will discuss this in more detail on Friday's interim call, but for > those eager for an advance look at rfc4474bis-09, the interesting = changes > are as follows: >=20 > Some text has been added to better explain verification service = handling > of multiple Identity headers, especially in failure cases. As a part = of > that, the response codes of RFC4474 have been amended slightly to take > into account the potential for multiple Identity headers, as well as = some > prior changes to the protocol syntax (like Identity-Info being = replaced > with the "info" parameter of Identity). Much of that was overdue = clean-up. >=20 > The authentication service and verification service sections now both = have > specific text about how "canon" is sent and received, as well as some > motivational text for "canon". Early implementer feedback suggested = this > was vague, hopefully it is more crisp now. The text about when and how > verifiers can prefer "iat" in "canon" over the Date header has been = beefed > up as well. >=20 > rfc4474bis now just points to PASSporT for the description of how = "mky" is > populated, as well as for all algorithms used internally within = PASSporT > to sign the headers and claims. For that reason, the algorithm = registry > defined by RFC4474 has now been deprecated. Certificate signing = algorithms > are out of scope of rfc4474bis, of course, and should instead appear = in > stir-certs. Also, the gatewaying section is gone - most of that > conceptually resides in the PASSporT spec now. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 5/25/16, 5:50 PM, "stir on behalf of internet-drafts@ietf.org" > wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Secure Telephone Identity Revisited = of >> the IETF. >>=20 >> Title : Authenticated Identity Management in the >> Session Initiation Protocol (SIP) >> Authors : Jon Peterson >> Cullen Jennings >> Eric Rescorla >> Chris Wendt >> Filename : draft-ietf-stir-rfc4474bis-09.txt >> Pages : 38 >> Date : 2016-05-25 >>=20 >> Abstract: >> The baseline security mechanisms in the Session Initiation Protocol >> (SIP) are inadequate for cryptographically assuring the identity of >> the end users that originate SIP requests, especially in an >> interdomain context. This document defines a mechanism for securely >> identifying originators of SIP requests. It does so by defining a >> SIP header field for conveying a signature used for validating the >> identity, and for conveying a reference to the credentials of the >> signer. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-09 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-rfc4474bis-09 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Fri May 27 08:22:59 2016 Return-Path: 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 8D52112D67C for ; Fri, 27 May 2016 08:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HVCobsYU92fU for ; Fri, 27 May 2016 08:22:56 -0700 (PDT) Received: from mail.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5B35112D6E0 for ; Fri, 27 May 2016 08:22:56 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id ACCA2F240C8; Fri, 27 May 2016 11:22:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id wC542NheiY-k; Fri, 27 May 2016 11:05:06 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 2B2AFF9C1A0; Fri, 27 May 2016 10:29:44 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 27 May 2016 10:29:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160527005150.14579.99232.idtracker@ietfa.amsl.com> To: Jon Peterson , Sean Turner X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] I-D Action: draft-ietf-stir-certificates-04.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 15:22:58 -0000 Jon and Sean: I do not think this document is ready for WG Last Call. In Section 4, the 4th numbered paragraph: we are going to use SHA-256 as = the one-way hash function in both cases. Please say so. In Section 4, the 5th numbered paragraph: we are going to use SHA-256 = for the signature carried in PASSporT. Please say so. In Section 5, the last two paragraphs are marked [TBD]. What WG = discussion is needed to resolve those? In Section 8, you ask whether we want to use IA5String, but the = alternative presented uses UTF8String. Since the string can only = contain digits, I think the bits on the wire would be the same except = for the tag. So, I recommend IA5String since it is easier to understand = the SIZE calculation and string comparison for an ASCII strings. In Section 9.2, there are two paragraphs are marked [TBD]. For the = second one, we want to use SHA-256. I assume that the OCSP responses = can be signed with either of the algorithms that are supported for the = certificates themselves. What WG discussion is needed to resolve both = of these TBDs? In Section 9.2.1, what WG discussion is needed to resolve the =93[More = TBD]=94 in the 3rd paragraph? The Appendix is missing the ASN.1 module. That is pretty easy to draft. = Of course, the object identifiers will be TBD until IANA assigns them. Russ On May 26, 2016, at 8:54 PM, Peterson, Jon = wrote: >=20 > This is a small update of the stir-certs document, to reflect the > consensus on algorithms that has been forged on the list here, and = also to > introduce a new "Certificate Usage" section that explicitly answers = the > requirements in rfc4474bis Section 6.4. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 5/26/16, 5:51 PM, "stir on behalf of internet-drafts@ietf.org" > wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Secure Telephone Identity Revisited = of >> the IETF. >>=20 >> Title : Secure Telephone Identity Credentials: >> Certificates >> Authors : Jon Peterson >> Sean Turner >> Filename : draft-ietf-stir-certificates-04.txt >> Pages : 19 >> Date : 2016-05-26 >>=20 >> Abstract: >> In order to prevent the impersonation of telephone numbers on the >> Internet, some kind of credential system needs to exist that >> cryptographically proves authority over telephone numbers. This >> document describes the use of certificates in establishing authority >> over telephone numbers, as a component of a broader architecture for >> managing telephone numbers as identities in protocols like SIP. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-stir-certificates-04 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-certificates-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Fri May 27 08:23:42 2016 Return-Path: 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 1E27B12D6BA for ; Fri, 27 May 2016 08:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0_TmIjMdF4O7 for ; Fri, 27 May 2016 08:23:36 -0700 (PDT) Received: from mail.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 069BC12D6E0 for ; Fri, 27 May 2016 08:23:36 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 59A87F240CE; Fri, 27 May 2016 11:23:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 36VeEpFcDbXk; Fri, 27 May 2016 11:05:45 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id A2FDEF241CB; Fri, 27 May 2016 10:43:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <20160524214118.14096.34219.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2016 10:43:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <06ED91A0-1B15-4937-9219-142BE5C1AFC9@vigilsec.com> References: <20160524214118.14096.34219.idtracker@ietfa.amsl.com> To: "Wendt, Chris" , Jon Peterson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-02.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 15:23:41 -0000 Chris and Jon: It looks like this document is getting close to WG Last Call. I have a = few comments and questions. In Section 3.1, please say that the PASSporT signature will be ECDSA = with curve P-256 and the SHA-256 one-way hash function. In Section 3.1, =93.crt=94 is used as a file extension. RFC 2585 says = that =93.cer=94 should be used in this case. Is there any problem = making that change? In section 3.1.2, I think the WG has decide to support on ES256. Please = remove RS256. In Section 3.2.2.2, there was a discussion about dropping the colon = characters just to make the PASSportT token smaller. Is there a reason = that was not done? Russ On May 24, 2016, at 5:41 PM, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Telephone Identity Revisited = of the IETF. >=20 > Title : Persona Assertion Token > Authors : Chris Wendt > Jon Peterson > Filename : draft-ietf-stir-passport-02.txt > Pages : 21 > Date : 2016-05-24 >=20 > Abstract: > This document defines a token format for verifying with non- > repudiation the sender of and authorization to send information > related to the originator of personal communications. A > cryptographic signature is defined to protect the integrity of the > information used to identify the originator of a personal > communications session (e.g. the telephone number or URI) and verify > the accuracy of this information at the destination. The > cryptographic signature is defined with the intention that it can > confidently verify the originating persona even when the signature = is > sent to the destination party over an unsecure channel. The Persona > Assertion Token (PASSporT) is particularly useful for many personal > communications applications over IP networks and other multi-hop > interconnection scenarios where the originating and destination > parties may not have a direct trusted relationship. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-stir-passport-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-passport-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Fri May 27 08:36:50 2016 Return-Path: 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 0962712D588 for ; Fri, 27 May 2016 08:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] 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 97m9kqtDV7O7 for ; Fri, 27 May 2016 08:36:47 -0700 (PDT) Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) (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 030C512D182 for ; Fri, 27 May 2016 08:36:46 -0700 (PDT) X-AuditID: a2962c47-753ff70000001931-11-5748698e1829 Received: from COPDCEX20.cable.comcast.com (Unknown_Domain [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id 93.91.06449.E8968475; Fri, 27 May 2016 09:36:46 -0600 (MDT) Received: from COPDCEX23.cable.comcast.com (147.191.124.154) by COPDCEX20.cable.comcast.com (147.191.124.151) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 27 May 2016 09:36:45 -0600 Received: from COPDCEX23.cable.comcast.com ([fe80::3aea:a7ff:fe36:88bc]) by COPDCEX23.cable.comcast.com ([fe80::3aea:a7ff:fe36:88bc%19]) with mapi id 15.00.1130.005; Fri, 27 May 2016 09:36:45 -0600 From: "Wendt, Chris" To: Russ Housley Thread-Topic: [stir] I-D Action: draft-ietf-stir-passport-02.txt Thread-Index: AQHRuCu+XTYxigqc0EGT3qZMI3JH45/M6s23 Date: Fri, 27 May 2016 15:36:44 +0000 Message-ID: <1036AF9A-510D-4759-A5E3-96B73F614FD5@cable.comcast.com> References: <20160524214118.14096.34219.idtracker@ietfa.amsl.com>, <06ED91A0-1B15-4937-9219-142BE5C1AFC9@vigilsec.com> In-Reply-To: <06ED91A0-1B15-4937-9219-142BE5C1AFC9@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsWSUDRnsm5fpke4weqp0havXtxktzjTYGmx fO02JgdmjyVLfjJ57Gh4zuyx6s4X1gDmKC6blNSczLLUIn27BK6M5gW7WAoaJStWzOhibWB8 LtzFyMkhIWAiMf/LNLYuRi4OIYEuJol3+0+wQziHGCXuz1/FCOGcZJS4uPUJM0gLG1DLl55f rCC2iIC6xN/5F9hBbGaBIIk3N9sZQWxhAXuJKf96GSFqHCROnLrCDmEbSdz+85QJxGYRUJVY s7+HDcTmFXCR+PCtEWymkECpxNStE1lAbE6g3gPzJoLtZRQQk/h+ag0TxC5xiVtP5jNBvCAg sWTPeWYIW1Ti5eN/rBC2gcTWpftYIOoNJN6fm88MYWtLLFv4mhlir6DEyZlPWCDqxSUOH9nB OoFRfBaSFbOQtM9C0j4LSfsCRpZVjHLJ+QUpybkZ+aUlBoZ6yYlJOal6yfm5yYnFJSB6EyMw /hZN03HfwXih1/kQowAHoxIPr0KyR7gQa2JZcWUuMLw5mJVEeD9lAIV4UxIrq1KL8uOLSnNS iw8xSnOwKInz9v2wDRcSSE8sSc1OTS1ILYLJMnFwSjUwhhyf1jpr0o6/i82u3RL+fX++9Iy8 AzutZ5wTzW08G7JrjdWJuh5bSbEH+Vzs3e8b34t6tk1aeFTjvZV3iW9b2Ywwxv/n2toFpleo H5+e5ylZHjZlmsBDdq4a33n69VGRxyeHcvh9uK/YJ+wQk1FQpjdNzXbj5shuif9527ayLH97 6Iq2+f5yJZbijERDLeai4kQAITQZALsCAAA= Archived-At: Cc: IETF STIR Mail List , Jon Peterson Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-02.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 15:36:49 -0000 We can discuss on the call but I am fine with all of these changes > On May 27, 2016, at 11:23 AM, Russ Housley wrote: >=20 > Chris and Jon: >=20 > It looks like this document is getting close to WG Last Call. I have a f= ew comments and questions. >=20 > In Section 3.1, please say that the PASSporT signature will be ECDSA with= curve P-256 and the SHA-256 one-way hash function. >=20 > In Section 3.1, =93.crt=94 is used as a file extension. RFC 2585 says th= at =93.cer=94 should be used in this case. Is there any problem making tha= t change? >=20 > In section 3.1.2, I think the WG has decide to support on ES256. Please = remove RS256. >=20 > In Section 3.2.2.2, there was a discussion about dropping the colon chara= cters just to make the PASSportT token smaller. Is there a reason that was= not done? >=20 > Russ >=20 >=20 >> On May 24, 2016, at 5:41 PM, Internet-Drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Secure Telephone Identity Revisited of = the IETF. >>=20 >> Title : Persona Assertion Token >> Authors : Chris Wendt >> Jon Peterson >> Filename : draft-ietf-stir-passport-02.txt >> Pages : 21 >> Date : 2016-05-24 >>=20 >> Abstract: >> This document defines a token format for verifying with non- >> repudiation the sender of and authorization to send information >> related to the originator of personal communications. A >> cryptographic signature is defined to protect the integrity of the >> information used to identify the originator of a personal >> communications session (e.g. the telephone number or URI) and verify >> the accuracy of this information at the destination. The >> cryptographic signature is defined with the intention that it can >> confidently verify the originating persona even when the signature is >> sent to the destination party over an unsecure channel. The Persona >> Assertion Token (PASSporT) is particularly useful for many personal >> communications applications over IP networks and other multi-hop >> interconnection scenarios where the originating and destination >> parties may not have a direct trusted relationship. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-stir-passport-02 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-passport-02 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=20 From nobody Fri May 27 11:16:56 2016 Return-Path: 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 7E31B12D711 for ; Fri, 27 May 2016 11:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9EK5B1AIApOZ for ; Fri, 27 May 2016 11:16:54 -0700 (PDT) Received: from mail.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7812DC6A for ; Fri, 27 May 2016 11:15:02 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 64AE3F2403B for ; Fri, 27 May 2016 14:15:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id xkHmuOiVzjNh for ; Fri, 27 May 2016 13:57:12 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 03D60F2401F for ; Fri, 27 May 2016 14:15:01 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <89C28985-AF81-4A27-807A-31BF670B3C7A@vigilsec.com> Date: Fri, 27 May 2016 14:15:13 -0400 To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] Credential Formats X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 18:16:55 -0000 In Section 6.4 of rfc4474bis, we are told the four things that must be = specified for STIR credential mechanisms: In order for a credential system to work with this mechanism, its specification must detail: which URIs schemes the credential will use in the "info" parameter, and any special procedures required to dereference the URIs how the verifier can learn the scope of the credential any special procedures required to extract keying material from the resources designated by the URI any algorithms required to validate the credentials (e.g. for certificates, any algorithms used by certificate authorities to sign certificates themselves) To date, we only have once credential format: certificates. Is anyone considering another format? If not, then we can improve = interoperability by nailing down that one. Russ From nobody Tue May 31 06:06:54 2016 Return-Path: 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 6CFA212D1D7 for ; Tue, 31 May 2016 06:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com 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 qeN4k8ltE1aZ for ; Tue, 31 May 2016 06:06:51 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA91E12D7AA for ; Tue, 31 May 2016 06:06:49 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id p34so20897168qgp.1 for ; Tue, 31 May 2016 06:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=VkoYHDF/yjcoA1/8bTn74GclV9dI3Wvdu+b1u47OEDQ=; b=g5VT20I4qZojSzOO2Z3ihKxhippJvxU+KcuBL3wJ5I3WIi4oruZxwH6/w+H7nZglcS bALpUrGM8yeLD5oPhM5suUDjVIk/xj+ijWgrM6aSz7osEj7SmiLluiCNLr6N2oumfwwC EtDEGvem5SUQ+1Q/wO0P7xZ96qhIJS+IP9938JeRXs2VNAOlWoQWadFDoqsHrwyEdVkd iKYAEeW5JMEVcXvsF58FaVvUoa/KrdYGNygQzHzorFtL6Ejxz8/Rr9YFx4DDbjbSBPxY R078Exe5EZRq5JWhgy8YalovaM98T+M8dJTjTH2Gc422oK5A9upnaXkb2MeLbdGieyGJ hNwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=VkoYHDF/yjcoA1/8bTn74GclV9dI3Wvdu+b1u47OEDQ=; b=BEhDzMeYmJvAiBfVG3TQttQskvkC/VwA7yhR/U96y5xRRefeTrg7ELAC23hqz5q5Eu rndyvbCdclGhmHv2QqKjSj41dJkv6NMlq05IwjZp4z6IW0kBOzptuSd7SOtpLRYAKyQu ikqXnx/Llv64q+Xpa/MYqJShQHUcTgXBldfKUvyzsNN1bkFxvKGXDp+M+QE5xm3ukFaN 2Xnni/Y6IOghXe+TaZI+81h7EBoZq6d8gzay/ORT3uX/NlEjQC5Jp0wz+RYVilZcmHqg T/OpHXvRW5xiBX601bzlp6U474dsy818RpgF+yMLI5u+WA+WL2NjtrL64SJoicmhAmmb juzQ== X-Gm-Message-State: ALyK8tKG5yYcynd9xmhoLpIEEeBdUn2nUjku08pEfpVLRLX9YvN2iIv1nW6FTCGm49+tIA== X-Received: by 10.140.36.167 with SMTP id p36mr30726308qgp.38.1464700008871; Tue, 31 May 2016 06:06:48 -0700 (PDT) Received: from ?IPv6:2601:a40:100:d3:757a:db8a:c51c:45c5? ([2601:a40:100:d3:757a:db8a:c51c:45c5]) by smtp.gmail.com with ESMTPSA id w6sm10820630qhb.2.2016.05.31.06.06.48 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2016 06:06:48 -0700 (PDT) From: Chris Wendt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 31 May 2016 09:06:46 -0400 To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [stir] 4474bis identity header - full JWT by default vs canon X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 13:06:53 -0000 Hi All, There was a discussion on the STIR interim call about whether there is = any strong reasons to consider using the full PASSporT = (header.claims.signature) as the default for the identity header in = 4474bis. The primary argument for the full token being default would be, it may = be more efficient from an implementation point of view to have the = constructed token available to the verification service to directly = validate signature. With the caveat that in either case you either need = to re-construct the header.claims or you need to decode the Base64 to = get the JSON header and claims to verify that the values correspond to = values in the SIP header. The primary argument for the current default of only including the = signature, is to save the 80-100 bytes of =E2=80=9Cduplicate=E2=80=9D = information in the SIP payload. Feel free to reword if i didn=E2=80=99t capture the main arguments = correctly. Would like to get other opinions or other arguments for or against = keeping things the way they are or considering just using the full = PASSporT token in the identity header. Thanks. -Chris= From nobody Tue May 31 17:25:43 2016 Return-Path: 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 AB20612B035 for ; Tue, 31 May 2016 17:25:41 -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 JlaYD9uxTuoF for ; Tue, 31 May 2016 17:25:39 -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 D1AAD12D13C for ; Tue, 31 May 2016 17:25:39 -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 u510Mkng020860; Tue, 31 May 2016 20:25:37 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 2377eqpasn-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 May 2016 20:25:37 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Tue, 31 May 2016 20:25:35 -0400 From: "Peterson, Jon" To: Chris Wendt , IETF STIR Mail List Thread-Topic: [stir] 4474bis identity header - full JWT by default vs canon Thread-Index: AQHRuz1eiVkbnTwgIUqW6iKnRchGG5/Tj3EA Date: Wed, 1 Jun 2016 00:25:34 +0000 Message-ID: References: In-Reply-To: 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.169] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-31_12:, , 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-1604210000 definitions=main-1606010002 Archived-At: Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 00:25:42 -0000 This is a point that Chris and I have discussed a bit before, and is one of those issues that is hard to resolve because the differences between the two choices are so small. >From my perspective, making implementations send "canon" by default, while leaving the option to exclude it, requires the same two code paths to exist as we do when we don't send "canon" by default, and leave the option to include it. And yes, the argument not to send it be default is simply to reduce message size, given the fields in canon are necessarily redundant with various hearer field values and parameters in SIP. In some environments, I still hear that message size is a concern. That's why we've set it this way now. It might turn out in deployment that we need "canon" more often that we'd think, because of things like Date header changes, say. I'd be willing to revisit this when we have a bit more experience under our collective belts. Ultimately, as Chris says, a verification service will need to basically reconstruct the header and claims itself anyway from the SIP request - or at least that the differences between reconstructing them on the one hand and extracting each individual field to compare them to the corresponding headers and claims of the canonical JWT object on the other hand seem unlikely to genuinely impact either the difficulty of implementation or the compute cycles required. But like Chris, I'm interested to hear people's thoughts on this, and I'm not deeply committed to either approach. Jon Peterson Neustar, Inc. On 5/31/16, 6:06 AM, "stir on behalf of Chris Wendt" wrote: >Hi All, > >There was a discussion on the STIR interim call about whether there is >any strong reasons to consider using the full PASSporT >(header.claims.signature) as the default for the identity header in >4474bis. > >The primary argument for the full token being default would be, it may be >more efficient from an implementation point of view to have the >constructed token available to the verification service to directly >validate signature. With the caveat that in either case you either need >to re-construct the header.claims or you need to decode the Base64 to get >the JSON header and claims to verify that the values correspond to values >in the SIP header. > >The primary argument for the current default of only including the >signature, is to save the 80-100 bytes of =B3duplicate=B2 information in t= he >SIP payload. > >Feel free to reword if i didn=B9t capture the main arguments correctly. > >Would like to get other opinions or other arguments for or against >keeping things the way they are or considering just using the full >PASSporT token in the identity header. > >Thanks. > >-Chris >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir