[stir] Proposal to change servprovider-oob to Standards Track (was Re: Shepherd Review of draft-ietf-stir-servprovider-oob-24)

Ben Campbell <ben@nostrum.com> Mon, 30 October 2023 21:45 UTC

Return-Path: <ben@nostrum.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 A33D8C14F748; Mon, 30 Oct 2023 14:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.885
X-Spam-Level:
X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MAY_BE_FORGED=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 mz5HGQoXYDLf; Mon, 30 Oct 2023 14:45:51 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF2FC15107E; Mon, 30 Oct 2023 14:45:50 -0700 (PDT)
Received: from smtpclient.apple (mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged)) (authenticated bits=0) by nostrum.com (8.17.2/8.17.1) with ESMTPSA id 39ULjxcX062774 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 30 Oct 2023 16:46:00 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1698702361; bh=K/f0pXFtCk9ww2X21YCzy/0H5ELs0HHM/e/QasKKAFc=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=U/lb5Ws4ywC9XVxlTg/GRPduC+TACMGa5xK/TOzTDZXGHcJz7L6MKGc3jDjv9Ap7Z U+M+F8E8IvOzqD0NPega20BOoXtPJZVoJ5Lbup2o8mlRAPpt1GzN+EfW9p7DBgMVN4 xORg9+SsAnlSWdVCK9Dyv6g0TDiSMfe8b0v3gCkw=
X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged) claimed to be smtpclient.apple
From: Ben Campbell <ben@nostrum.com>
Message-Id: <B7BA36CF-AF33-4056-BA2E-E89B1B6ED287@nostrum.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_89AAE254-0684-48F6-A3BE-5C6FF797E973"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Mon, 30 Oct 2023 16:45:40 -0500
In-Reply-To: <CO6PR17MB49784E2CCF28CA0A7D4C933FFDD8A@CO6PR17MB4978.namprd17.prod.outlook.com>
Cc: STIR Chairs <stir-chairs@ietf.org>, "Peterson, Jon" <Jon.Peterson=40transunion.com@dmarc.ietf.org>, "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF STIR Mail List <stir@ietf.org>
References: <C9898106-3EF7-47E0-9588-4A413DBC25CB@nostrum.com> <CO6PR17MB49784E2CCF28CA0A7D4C933FFDD8A@CO6PR17MB4978.namprd17.prod.outlook.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/Eu5zyTOrFYpe1ixWV22JNGXRn_Y>
Subject: [stir] Proposal to change servprovider-oob to Standards Track (was Re: Shepherd Review of draft-ietf-stir-servprovider-oob-24)
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, 30 Oct 2023 21:45:55 -0000

(+ Murray)


Hello STIR wg:

Please see below that Jon proposed making this draft standards track instead of informational. This will create a normative downref to RFC 8816. As an individual, I think that is the right choice since there is some important security and security-adjacent guidance in the draft.

Does anyone object to that change? If so, please speak up really soon now.

Thanks!

Ben.


> On Oct 23, 2023, at 3:51 PM, Peterson, Jon <Jon.Peterson=40transunion.com@dmarc.ietf.org> wrote:
> 
>  
> Thanks for the read-through Ben. A few responses inline below.
>  
> Jon Peterson
> TransUnion
>  
> # Substantive:
>  
> ## General:
>  
> Is informational still the right status? It has quite a bit of normative language. There’s nothing inherently wrong about that, but that sort of thing does tend to trigger AD questions. If “Informational” is still correct, I suggest adding a paragraph somewhere early in the document to say why we think that and why we still included 2119/8174 language. IMO, this would be helpful both to head off questions in advance and to help end-readers understand how to think about the document. (I suspect the fact that 8816 is informative is a lot of the reason, but there are work-arounds if we think this document effectively defines a standard.)
>  
> I’m happy advancing it as PS, and having a downref to RFC8816. I think we went back and forth about that at one point. The respin will have this as std. 
>  
> ## §4, 2nd paragraph: “ The advantage to signing with STIR certificates is that they contain a "TNAuthList" value indicating the telephone network resources that a service provider controls.
>  
> Unfortunately, here, the biggest current deployment of STIR mostly still just puts SPCs in TnAuthList. The ATIS approach effectively allows any SPC token holder to attest to any phone number.
>  
> I thought “telephone network resources” was vague enough that it does not entail TNs as such, or at least, that was the intention. Any CPS that cared to check could consult the relevant industry databases or analytics to make a determination whether a carrier with a given SPC should actually be uploading a PASSporT from that “orig.” Or, SHAKEN-style, it could just take everything and leave it for terminating-side analytics to make the similar determination. That seems more like a matter of local policy than bits on the wire.
>  
> # Editorial:
>  
> ## Abstract, last sentence: If we stick with “Informational”, I suggest saying “This document describes” rather than “This specification defines”.
>  
> Again, since we’re pushing this as PS, I’ll just stick with the current language.
> .
> ## §1, 2nd paragraph:
> ###  “… and who thus will learn about the parties to communication independently…”
>  
> The phrase is a little hard to follow. I suggest “...Who thus will independently learn about the parties to communication…"
>  
> Agreed that isn’t great. How about: “and thus who will necessarily know the parties communicating”.
>  
> ### “… like mobile networks …”
>  
> Given that modern mobile networks tend to use SIP, they might not be the best target to pick on. Maybe something like “such as legacy non-IP telephone networks”
>  
> Okay.
>  
> ### “ where in-band transmission of STIR may not be feasible:
>  
> s/STIR/PASSporTs
>  
> Okay.
>  
> ## §10, first paragraph: "This draft mitigates those concerns by making the CPS one of the two parties to call setup”
>  
> In the gateway case, there may be more than 2 parties to the call setup. I suggest changing “one of the two parties” to “one of the parties”.
>  
> Okay, done. Thanks again!
>  
>  
> _______________________________________________
> stir mailing list
> stir@ietf.org <mailto:stir@ietf.org>
> https://www.ietf.org/mailman/listinfo/stir