Re: [stir] Comments on rfc4916-update
"Peterson, Jon" <Jon.Peterson@transunion.com> Mon, 23 October 2023 20:57 UTC
Return-Path: <Jon.Peterson@transunion.com>
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 AF69EC16F3F3 for <stir@ietfa.amsl.com>; Mon, 23 Oct 2023 13:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transunion.com header.b="AYMmSnBy"; dkim=pass (1024-bit key) header.d=transunion.onmicrosoft.com header.b="K73R1W73"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaCFunInjDpI for <stir@ietfa.amsl.com>; Mon, 23 Oct 2023 13:57:37 -0700 (PDT)
Received: from mx0b-00030c01.pphosted.com (mx0b-00030c01.pphosted.com [67.231.153.155]) (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 63B10C16F3EC for <stir@ietf.org>; Mon, 23 Oct 2023 13:57:37 -0700 (PDT)
Received: from pps.filterd (m0216088.ppops.net [127.0.0.1]) by mx0a-00030c01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39NKoH8L002023; Mon, 23 Oct 2023 15:57:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transunion.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=tuppdkim; bh=FzMK2a3dtpw7Rj35ieNdDMkwiYheZYeia3OV8RicVH4=; b=AYMmSnByd0Nwa16vmkwo2HLa6s23XMwP97U1FfgZA28NGc7Ha06VjJqzzEzDGiZLgK2p XqQMBrBkoUDCS9zgdwvZ1RitYhHkLC07N1Uvttf9qTGOM4q2PL3Z/ChwmlYOl3tmAyTD CGUdFS2X1przr6K5rGZE4DXIfgUGb2hXl77MaIHurrnjzwAdNFIyOeIJYqet6i30LbME 47znxIaM7hRQ+r2G7nLKN3vZsJVYp5Qb/4Ba0d4eUMrzkQ/1wAsYeSvrpj3P6THCRWN5 2M4l6pJZjYPUun7Ozyu9d39uh9w6aU6uuOoLyFr16u1hCN595L57LGutfyrlHerWXYQ0 aA==
Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04lp2040.outbound.protection.outlook.com [104.47.73.40]) by mx0a-00030c01.pphosted.com (PPS) with ESMTPS id 3twn8ytgcq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2023 15:57:36 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S42DnlPpBNBorvdIj7mtn0Wuu3aB2IPMhD6NWqR8mCc/UkimLdDpdSYHsW3tjczYcpWLFFAgs5Dhf2jUCMJpOlavhRR3e8hz7rQeAot/FNYO70BhPwGM6ARRBW3kt3xbmYn0+m8DXjhEHAfGwOhQKBGwgQYl0VxWjhgGCH8hjppMA6b5Qahne7JjprbvJaHNjJuoNgRDR3GuG3O9jL6ynUkMFUtJifdITWs63LvGCuUhBGNf/rUuytWGFyP7N2elAdTVhQX0uChaYljqpEauTbqWKy+xrffL+t7Dsw5dOKyjKYIu5T68gGi/7r8RlVFGFtiimMFLxSMdR3+DzaZphw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FzMK2a3dtpw7Rj35ieNdDMkwiYheZYeia3OV8RicVH4=; b=JxeY3nV7B3WGBCOKvTZScOCB4A7IhVbeJEhufhnmyB2a+NHrZHpM5QE+STm0IaAMn0p5biozMMEte4kv6s9fSoUPIWiZDuxrny+nMF9AGQpjE+lYr9vHDtBeDwU7s9/ZHR2JKJXg2kJYrHlJSppuWookf2WhRZQxpP4eumc6HVqXv80gnMOaEz31BLYE11nSJb3Z0K98yPNK4D5UKQTarKvDio/QJu/+uWVD4HLPeyboIQpfz3c//EHvjyktLbyzthONISREt37geEmmMiLwIDZLFvLOvHAaCPjmNZMniAhBBxz8cvdZxRJPSBP/IjKL7fQEiwvEL1n0rItVCuVw6Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=transunion.com; dmarc=pass action=none header.from=transunion.com; dkim=pass header.d=transunion.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transunion.onmicrosoft.com; s=selector2-transunion-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FzMK2a3dtpw7Rj35ieNdDMkwiYheZYeia3OV8RicVH4=; b=K73R1W73GZp1N5mp+lJGUJwSloeCSvd8vgAB/V3wVm1HtOBjyhghiKCMUdPu0IKBEYF3zD8/LHSY9z5reOpk8W5/Ya1iFAxPkdC/tvzelQm8Hnra10NoQB8oMc2/eQBdO3jRsfypjAIHt87XTDsG8IQMpxoZkuNy19rS08AuyDc=
Received: from CO6PR17MB4978.namprd17.prod.outlook.com (2603:10b6:303:139::23) by BY5PR17MB3812.namprd17.prod.outlook.com (2603:10b6:a03:231::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6933.11; Mon, 23 Oct 2023 20:56:33 +0000
Received: from CO6PR17MB4978.namprd17.prod.outlook.com ([fe80::3dbf:226d:4592:f872]) by CO6PR17MB4978.namprd17.prod.outlook.com ([fe80::3dbf:226d:4592:f872%6]) with mapi id 15.20.6933.014; Mon, 23 Oct 2023 20:56:32 +0000
From: "Peterson, Jon" <Jon.Peterson@transunion.com>
To: Jonathan Rosenberg <jdrosen@jdrosen.net>, "stir@ietf.org" <stir@ietf.org>
Thread-Topic: [stir] Comments on rfc4916-update
Thread-Index: AQHZwWid5MFJ9a+CnUiHbvL/Cwtce7BYASvJ
Date: Mon, 23 Oct 2023 20:56:32 +0000
Message-ID: <CO6PR17MB4978EB85F36812322507BE95FDD8A@CO6PR17MB4978.namprd17.prod.outlook.com>
References: <CA+23+fH4Zr5ZsgnmNnVNfGswkV8969X1nfk4e1ZdyRik0A2N8A@mail.gmail.com>
In-Reply-To: <CA+23+fH4Zr5ZsgnmNnVNfGswkV8969X1nfk4e1ZdyRik0A2N8A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CO6PR17MB4978:EE_|BY5PR17MB3812:EE_
x-ms-office365-filtering-correlation-id: bd73ec55-a17e-4219-d7be-08dbd40a896e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0WJA8/Wmc1kJfLzAMjGiFhvUGjae9+GFdtXxM2Gyl3DjJCD4SqIVfJG0FsU71TQQAgwRgI7riKmXoI51YdaMQ+2W5zZsXa3rRfHZb9eM45HVTdzF9GzNTIGLcoVZdOymJ4zo4sJrzQsDnDK0KqLDlY7QtlwOjCxWOEU7YwdQ5pmmkVMvSdCNRZfvpST2megqg0EWvEIHI3hvQKk0p2Cz+HzaTCOit8pZaHmFH2BpeO1LSU625f7jwEGDomQG64UNI/sq1WPwlai5hMi0NQgBFtRsPTTBzwIiAc3DJZPcwIBG/6Xc7FIU793taxbcShWCEsusTOySOfd9JDKaujK/KqrWhhiBHc96CpGrL75hOZo4Sr5mdr30m3n7ZCc4REdzDBAxXLWvniWf4veantuKfLY0HUjDYm5eVH3RTX5RNZhFJJciDDRQ9U0cn/rUiKQCUgUBg/RAfzq+oMDpWrMkQXL+Dze7pupijnPcP9NTGbhzbYyQcxLw+bL+qJwwH5ducZRHTURgtgLQwEfkbhygU32uhCcTByMB9YLJtYB6bNeeWRpMzVo1NVAso9w71zJV7bj/LqWKG4CX6hEro11KbJea0tkC1TSQZKraYCYuIeg=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR17MB4978.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(346002)(396003)(136003)(39860400002)(366004)(230922051799003)(1800799009)(451199024)(186009)(64100799003)(38070700009)(86362001)(2906002)(55016003)(15650500001)(5660300002)(8936002)(52536014)(8676002)(41300700001)(38100700002)(64756008)(316002)(66446008)(71200400001)(6506007)(110136005)(66556008)(76116006)(966005)(478600001)(33656002)(9686003)(26005)(166002)(83380400001)(66476007)(7696005)(66946007)(122000001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: llEbkI8L8Zug8waXH4cAkE60r0WKKtzelbOmoLqQdWGfbZ3NJ7pflTOSKKp/7DkUFIhEoUoauOz5hA6QU0Assvt0wLchWhpJCT60HyYzZyu8DvMGeNjHrpZXmNuzjUEF+W9YUFY72RK+0tkYCFI92RkKEo1ShAs8zWsAaCXFgNRJhBA3PbK8H4PVkvPeoZ3zAcRWVZ42hqMjJav18uHfYNnSm2rRaVFz7BDx5vFYzXtFChRNEvchabxwu4ESSNhYh8MOJTyigFrGWkbiG45VzTuJLYfG5F1VATt3yF34RjlA3ntf/ZMmiMM/zNqbuTEZIWgYn4SMoqQYZSGJVKPZIgvEZkBEpPyiZOOPR5QJ5MCSCu8oEcxsDNzzbY2pe6LMaQkN1wDDuG8tCBEfwMbecaYHhKMJayxEYSSVDohVEOYQBOducnjGr/TNKusD4ilbAMISFEt/Hd/9ZE3EGLvIhN0fBHhIwpPBrs76YoMP5QiYM3hAWIDusYg3LqygEqrKH5NxZpYtMnGzVyDKZf8cL5Pu0aDW5OoC652EKx1AsRAfdjuXDJOR0Ox7ABeCtb/ZMdZmuboGlzl+IxhEiIqSgrqduqjWkD5GDgJWgFMstIwJPpqbNHQP0C9yUtX+nLyRfAkfD+pvV2U+66mmhnublVkZL49bRY3wOj9sYTUjjMBaX0b3CWAQoLKEqxgtlaaZdU52Zu1TUHMuN6pSHARsCoWL40AkORckj/DGNBKZqvmmD8RghG5Zt7w7pMZ1PzDP7e8mt9dHJ+NkRzHU3gfY/T+l6oCgh5NYYRadoMcwxJBSIuhpc0NAc61EZigS9cRvBKWf8P7RnIryPxMyOw51RFIZ5ZHffPDxHc6TlaVpG3PZ0j90z7QHzDefIdI1Yaz83MS7Bz4qp9Oe3aGKA7MZ9yZ8t/5ZljuEXTUS1QTsp4n5oUyPZ+w8rZ80k21mfgvkWfC7W3Mj1zfKHzEXqLI4NDJmoXPl4We0UYQQs8nojaQAuyf3d8ZdXvjqTqlbirZW9YMZx29ti9bgmrNG8Aa3jghKuzlm7VVZYTA9ZkZxSVUvLOnf58fQRtppbM2DFkg3afuRC6p8Qd8ehPAO/3K7JJAeVbNaXo3FbW9M3Vl5dCvp8rpWXD74HYojw5V3HhS7QgQk0GOmxSeR0HQXVKOaEzT2u5jG7XPLWtT977ABybJ3uNxZO8y6A+okGys5UuhBL0PtfS3GRG8nRYeCXn52HxXRNgJZhQsUmQ2uS7ziDu3AMeSDcc/4GMdHS86ayTsnf8Ef53JfIcHDqNLvV2By3RT1wC/W+Kp4I1At2LHfU/YVuHfvs0KzGHS46sPgVIZ5R2NXXTQxRpPQ1gzCIcviAALQQZgTcYmVwiurzab5x3eqLpdzQkR1JlnW86MOvOmBuMy2OJmwxrYNJcCQYTDAtntjtt3wQvAGsO+w4LlGJGyQLAPfeZtnzGpvBz5e2oWxzaMNke6FC5/NJXZXDypSyByrf4ABA1rOD5VGSM72wWIJj10YohI/XJMAAcqvjxHIbN2Gw7IuwO7ssawmUDiJAtyDWcIL2Vbzqphlh71jZMtJnSkS3cwNdghaUJALnFiCpAtNwSawiuX8jnm6B2KOmV9h0VHMZjMBGn4V+wh5k+A=
Content-Type: multipart/alternative; boundary="_000_CO6PR17MB4978EB85F36812322507BE95FDD8ACO6PR17MB4978namp_"
MIME-Version: 1.0
X-OriginatorOrg: transunion.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO6PR17MB4978.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bd73ec55-a17e-4219-d7be-08dbd40a896e
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2023 20:56:32.2935 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0685d760-4332-4f24-b2ea-ffbbc2383f15
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AThH96SlTsLPp/6MRrZ20+C8w13mpmkHXB4q9hWduoL7kZ6nmEPA2XBZB0pjNYth9iRdgIHfBBuCQQhyIvMQtCUCt7y4nv6oa7h6cd0viB8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR17MB3812
X-Proofpoint-ORIG-GUID: eWlK2eD2YTQRDTJRNkGM7ai_Bc6FH4-w
X-Proofpoint-GUID: eWlK2eD2YTQRDTJRNkGM7ai_Bc6FH4-w
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-23_20,2023-10-19_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 suspectscore=0 phishscore=0 clxscore=1011 impostorscore=0 adultscore=0 priorityscore=1501 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310170001 definitions=main-2310230184
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/47oaIekixVUnTdTDmU3-wjLgxBE>
Subject: Re: [stir] Comments on rfc4916-update
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Oct 2023 20:57:41 -0000
Hey Jonathan, Thanks for the notes on this document – we discussed most of this at the mic back in SF, but I figured I’d capture this here for the record, so responses below inline. Jon Peterson TransUnion There is another interesting use case for this spec that is not mentioned in the intro. Specifically, when calls are placed by automata for the purposes of verifying ownership of phone numbers, it is really important that the call has not actually been forwarded. One can imagine that the entity performing the call to verify ownership of the number, would want to receive the rsp passport and check that it matches the called number. This would actually address some of the concerns that have been raised about the insecurity of forward routability checks for verifying number ownership. Added. On this: > An "rsp" PASSporT that signs a different "dest" than the one that appeared in the PASSporT of the dialog-forming request MUST send at least one "div" PASSporT with it. If no "div" PASSporTs were received in the dialog-forming request, then "rsp" PASSporTs MUST NOT be used in responses. I think this MUST is overly harsh. The entity sending the rsp passport has no control over whether intermediaries inserted div passports along the way. If none of them do, it means that the rsp passport can never be sent and this spec is useless. Indeed, for the use case I outline above, the originator of the call doesnt need the div passports at all, just the rsp passport. As we discussed at the mic in SF, this is just a case where the second sentence above was meant to build on the first, but taken in isolation, it reads wrong – which is fixed in the new version. If the “dest” is changed, and there’s no “div” received by the terminating side, this spec is not applicable, as I think we agree on. Broadly, if you place an TFA call to 2125551212 and got back a “rsp” from 2125559999 (with no “div” explaining why), what are you supposed to do with it? You certainly shouldn’t trust it any more than you would a call with no connected identity at all. As to whether anyone should trust an unexpected “rsp” “dest” accompanied by proper “div”s explaining that the call was legitimately redirected, I think we can just call that a matter of local policy – I think it’s pretty trustworthy, but there could be differences of opinion on this matter. We at the IETF can leave that up to the conscience of implementers/deployers – the protocol machinery is there for people who do want to trust it. On this: > The use of the connected identity mechanism here specified is not limited to provisional dialog requests. Once a dialog has been established with connected identity, any re-INVITEs from either the originating and terminating side, as well as any BYE requests, MUST contain Identity headers with valid PASSporTs. It seems odd to me that this spec would require the originator of the call to take extra actions (namely, including passports in mid-dialog requests) just because the terminating side decided to add an rsp passport in the 200 OK response to the INVITE. Broadly, I see the scope of this draft as mutually authenticating requests in a dialog, not merely protecting call setup, due to the various fraud use cases involving later in-dialog signaling that are described in the draft’s motivation. As we also discussed in SF, I’m willing to slip that down to a SHOULD. I’m treating receipt of an “rsp” like a capability negotiation, effectively. I can tweak the text there a bit to support the case where the originating side does not understand “rsp”, which it doesn’t really account for now, but basically the intention is that if both sides support connected identity, they should apply it to all mid-dialog or dialog-terminating requests. I have a hard time imagining a case where support is established and both sides wouldn’t want to have relevant requests signed… but that is more a SHOULD than a MUST. Along similar lines, this seems a bit onerous as it introduces requirements on the caller that have nothing to do with connected identity per se: > It is however REQUIRED by this specification that if a UAC sends a CANCEL for its own PASSporT-protected INVITE request, that it include an Identity header with a valid PASSporT in the CANCEL. Yeah, due to HERFP etc. CANCEL just doesn’t work – too many CANCELs can come from entities other than the UAC, so, it’s too complicated to try to make this work. I’ve downgraded this text to say that it is not forbidden for UACs to send CANCELs for their own requests, but that relying parties should not expect to see them. This too, seems like it is more appropraite as a SHOULD, in cases like I outline above where the div chain itself is not interesting to the caller: > Mid-dialog requests also require special handling in diversion cases. Implementations compliant with this specification MUST validate the "div" chain back to the "rsp" PASSporT on any Identity header field values received in responses. This is another case where, again, the sentence out of context reads wrong and needed a fix. I still think that if you are going to rely on “div” for these redirection cases, you do need the “div” chain to actually validate the “rsp”. But we don’t want to turn that into a MUST for validation for those people whose local policy is just not to care about “div” at all. Thanks again. -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net<mailto:jdrosen@jdrosen.net> http://www.jdrosen.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jdrosen.net_&d=DwMFaQ&c=7gn0PlAmraV3zr-k385KhKAz9NTx0dwockj5vIsr5Sw&r=rQo6AhlF8tKhxgONBTTPp2dKudYXajoA6N78vvkOkzA&m=PWlNE9fIu4EkzmoZJeJjofVZXbYbi6kFJ4ueYnKoFUOJxssIifRgINsvlNbSiLSB&s=8-bwIJlWl9oKmaC072A7pGrwevBdj2Dz2B9HnBCYRd4&e=>
- [stir] Comments on rfc4916-update Jonathan Rosenberg
- Re: [stir] Comments on rfc4916-update Peterson, Jon