Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-02

Paul Kyzivat <paul.kyzivat@comcast.net> Sat, 23 July 2022 18:49 UTC

Return-Path: <paul.kyzivat@comcast.net>
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 0B9C0C13C518 for <stir@ietfa.amsl.com>; Sat, 23 Jul 2022 11:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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=comcast.net
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 7bNGaiYiriJt for <stir@ietfa.amsl.com>; Sat, 23 Jul 2022 11:49:53 -0700 (PDT)
Received: from resqmta-h1p-028592.sys.comcast.net (resqmta-h1p-028592.sys.comcast.net [96.102.200.5]) (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 583FEC13C510 for <stir@ietf.org>; Sat, 23 Jul 2022 11:49:53 -0700 (PDT)
Received: from resomta-h1p-027914.sys.comcast.net ([96.102.179.199]) by resqmta-h1p-028592.sys.comcast.net with ESMTP id FK35o1v8THt8CFKAJocmxI; Sat, 23 Jul 2022 18:47:51 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1658602071; bh=YCixJ81Oy3LCAifjFXDbXp28Whgepaj2m91tNG1wOF8=; h=Received:Received:Message-ID:Date:MIME-Version:From:Subject:To: Content-Type; b=191My97tEXvvTwD0ukX0G/BTZDa1M79bW6drIJBuI/ZrqKv/NWucj5+I8F8Bb9RPx rDitpDskFmkofsvsA/Et3Z5G3WObs/Fc8YXPMUrSIKBva6LmeOUzTEDLXYQCVneyqc FxWhmAIHj98Rj0zWAfPyT3Tw+rKdFA5v/crXVRFgDGkuyMuyYy5C8ez2GGRYc4dngv lURVtEXPW0HlE6Y+W4QryX1+iK05UAhsaZKnJHhTZnUAbcTBiKRpaI/y/Wtsk0QbHX WCcNNLOYFNZTBjApfjOSGSumD6yXPqDlwPVDH9prohTejlX0kRaic7lNpJICKw7lhr 0zMhzQBUR+09A==
Received: from [192.168.1.52] ([24.62.227.142]) by resomta-h1p-027914.sys.comcast.net with ESMTPA id FK9soLNy22V98FK9toKoqI; Sat, 23 Jul 2022 18:47:26 +0000
X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvfedrvddtgedgudeffecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecunecujfgurhepkfffgggfhffuvfhfjggtgfesthejredttdefjeenucfhrhhomheprfgruhhlucfmhiiiihhvrghtuceophgruhhlrdhkhiiiihhvrghtsegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeffffeuueevkeduvdeftdelgeeufeekheevheejtdevveegvdejffeuudekfeefgeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedvgedriedvrddvvdejrddugedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurdehvdgnpdhinhgvthepvdegrdeivddrvddvjedrudegvddpmhgrihhlfhhrohhmpehprghulhdrkhihiihivhgrthestghomhgtrghsthdrnhgvthdpnhgspghrtghpthhtohepuddprhgtphhtthhopehsthhirhesihgvthhfrdhorhhg
X-Xfinity-VMeta: sc=0.00;st=legit
Message-ID: <86c3441e-986a-2409-64c3-2d911c2b22cb@comcast.net>
Date: Sat, 23 Jul 2022 14:47:26 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
From: Paul Kyzivat <paul.kyzivat@comcast.net>
To: stir@ietf.org
References: <5393b70d-bfc7-c8ac-eb8d-30c8087a1e89@nostrum.com> <A47A285A-C230-4277-91D8-FE6D5F88735C@vigilsec.com>
Content-Language: en-US
In-Reply-To: <A47A285A-C230-4277-91D8-FE6D5F88735C@vigilsec.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/cS_G1XvKIRcsHduZeFFEoJvI7DA>
Subject: Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-02
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: Sat, 23 Jul 2022 18:49:57 -0000

Here are thoughts I have after reviewing this document:

* Section 3:

This document is depending on draft-sparks-sipcore-multiple-reasons for 
an extension to the Reason header field permitting multiple reasons for 
the same protocol. That is an individual draft and is currently expired. 
IMO *this* draft should not complete WGLC until that draft is adopted 
and completes its own WGLC.

Also, I think this draft should be more explicit in stating that the new 
STIR protocol it defines permits multiple uses, and perhaps constraints 
on how. (E.g., in what ways the multiple uses must differ, or how to 
resolve ambiguities among them. I *think* the response codes defined in 
RFC 8224 are mutually exclusive for a single passport, so perhaps 
constrain to a single cause per ppi.)

I'm inclined to think that draft-sparks-sipcore-multiple-reasons ought 
to revise the IANA registry to include a new column that indicates 
single or multiple use. If so this document would need to include that 
field in its IANA registration.

* Section 7:

Requiring unconditional removal of the Reason header field seems an 
excessive remedy for the stated problem. It should be sufficient to 
remove the ppi parameter. And is even that needed if the ppi value is in 
compact form?

* Section 8:

The Protocol Cause for the STIR Protocol Value is specified as "Status 
code". This is the same as is defined for the SIP protocol. The values 
used for STIR as a subset of the SIP Protocol Causes. It isn't clear 
what values are valid for use here. I guess you intend the values 
specified in section 6.2.2 of RFC 8224. But defining that way isn't 
future proof. What if a subsequent extension/update to RFC 8224 defines 
some additional codes?

I'm not certain what the best answer is here. I think it is worth some 
discussion.

	Thanks,
	Paul

On 7/12/22 9:34 AM, Russ Housley wrote:
> At the STIR Working Group Virtual Interim on 22 April 2022, we agreed to start WG Last Call for this document once an updates was posted.  It has now been posted.
> 
> Please send reviews to the list by Noon Eastern time on  in 26 July 2022.  This is a few hours before the STIR session at IETF 114.
> 
> If you plan to provide a review but need more time, please let us know as soon as possible.
> 
> See <https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4916-update/>
> 
> For the STIR WG Chairs,
>   Russ
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir