Re: [stir] quoted ppt parameter value redux

"Asveren, Tolga" <tasveren@rbbn.com> Fri, 04 October 2019 20:39 UTC

Return-Path: <tasveren@rbbn.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 8B36D120025 for <stir@ietfa.amsl.com>; Fri, 4 Oct 2019 13:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 fTGifb_n_0qp for <stir@ietfa.amsl.com>; Fri, 4 Oct 2019 13:39:44 -0700 (PDT)
Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2097A120013 for <stir@ietf.org>; Fri, 4 Oct 2019 13:39:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1570221582; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BYGr2u93I96aN/HrIBCqyFYxzSbOVvs3jGCa4QTMdhg=; b=eENrIsdQdRtINOO24tAi9q2Cnis+81zLWckku8ZPjnIKDvvo6F/zEsWRRK8AhGSdMw/6LN Q6KjpHhjltOprzyokmB43+OA+XUWR9pIwUW4+FQ8ir6cK8+sZzDG083Q/A2tX09rT5UTrh d/NjgP0UxQ+R49D1n4Dn3p76oSbzPCE=
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2052.outbound.protection.outlook.com [104.47.46.52]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-257-DNNO2biQMT2OQlcNWKsorw-1; Fri, 04 Oct 2019 16:39:40 -0400
Received: from DM6PR03MB4731.namprd03.prod.outlook.com (20.179.104.141) by DM6PR03MB4124.namprd03.prod.outlook.com (20.176.120.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.23; Fri, 4 Oct 2019 20:39:37 +0000
Received: from DM6PR03MB4731.namprd03.prod.outlook.com ([fe80::5ce6:cc23:95d7:a68]) by DM6PR03MB4731.namprd03.prod.outlook.com ([fe80::5ce6:cc23:95d7:a68%7]) with mapi id 15.20.2327.023; Fri, 4 Oct 2019 20:39:37 +0000
From: "Asveren, Tolga" <tasveren@rbbn.com>
To: Subir Das <subirdas21@gmail.com>, Chris Wendt <chris-ietf@chriswendt.net>
CC: "Peterson, Jon" <jon.peterson@team.neustar>, "stir@ietf.org" <stir@ietf.org>
Date: Fri, 04 Oct 2019 16:39:37 -0400
Thread-Topic: [stir] quoted ppt parameter value redux
Thread-Index: AQHVeg/ISMi94GnCLEyL2tqq3RscQqdJW7mAgAANogCAAYfnYA==
Message-ID: <DM6PR03MB473148FDCE718A19CA4BDE55A59E0@DM6PR03MB4731.namprd03.prod.outlook.com>
References: <79880B31-1AAC-45FD-A60D-CBFF01B584AE@team.neustar> <9650A5C9-723A-4E9E-84FF-88A7CE087A37@chriswendt.net> <CAFb8J8qcoTpJupMxQ0==R2KPkVz-hJfNdD5a0aDMrG30zj9S2g@mail.gmail.com>
In-Reply-To: <CAFb8J8qcoTpJupMxQ0==R2KPkVz-hJfNdD5a0aDMrG30zj9S2g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@rbbn.com;
x-originating-ip: [73.80.74.66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 99e402d0-f40e-493e-ac94-08d7490af946
x-ms-traffictypediagnostic: DM6PR03MB4124:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DM6PR03MB41247D8402D8161275D2F221A59E0@DM6PR03MB4124.namprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 018093A9B5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(366004)(136003)(396003)(189003)(199004)(81166006)(81156014)(8936002)(74316002)(790700001)(66066001)(6116002)(3846002)(256004)(14444005)(486006)(52536014)(229853002)(9686003)(476003)(4326008)(11346002)(6246003)(55016002)(6506007)(186003)(236005)(71190400001)(71200400001)(86362001)(7736002)(6436002)(53546011)(5660300002)(102836004)(6306002)(54896002)(8676002)(446003)(26005)(76176011)(33656002)(110136005)(54906003)(14454004)(99286004)(606006)(25786009)(66446008)(66556008)(64756008)(66476007)(76116006)(66946007)(2906002)(316002)(966005)(478600001)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR03MB4124; H:DM6PR03MB4731.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PinbJ9lPWbaTyzMDhIkS+KYTMaq1A5EA3bXwsjuhcDnFEnH/U36P/+VtUJE+tkoKHnLibpdZQfcn8ntfXt2mGUpTibE34itqr7rlPy1VQgodwkGR2ebpQs0ug/HWAk91a2bhoIHjdoIYDUdNckhjcjWirgUAwgDKnb1hqmyxvlTx6NIwwxxHwRrL54LpDHu1oUp/a0luq35pDEYPDTEpzY/60d1RtemJCj8t0t4sfZOxRRHxD5jbye6+b9CgsLEXDJDq9T8ihEVKXgtt+3WxRsSKqPzvZXyx00360PdW24iQsWVat1oo4lX9N4Jy8KnWtdmkFNFtFmfoGkr+gIQtAWFjnc6iOSy3HhW7MPwCCNHQ0ltMsE5Sacewo4iz5G6PElGp7Q49UgLwMwwnmfPhtTYhfMedpffwZmnYYCsWTKnRLcbwhD8VqLMAYW542w6Pp+JzD/ZQBTyTNzF7LmdMvQ==
x-ms-exchange-transport-forked: True
x-originatororg: rbbn.com
x-ms-exchange-crosstenant-network-message-id: 99e402d0-f40e-493e-ac94-08d7490af946
x-ms-exchange-crosstenant-originalarrivaltime: 04 Oct 2019 20:39:37.5604 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
x-ms-exchange-crosstenant-mailboxtype: HOSTED
x-ms-exchange-crosstenant-userprincipalname: 8o4BbEI8p0c27J8w8il6+zt7gxIlefy/6zbnWctC2/TWHps5y84Ke9m5gdZlQeW7FH6KsaBKN8V9podUedHnhQ==
x-ms-exchange-transport-crosstenantheadersstamped: DM6PR03MB4124
x-mc-unique: DNNO2biQMT2OQlcNWKsorw-1
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_DM6PR03MB473148FDCE718A19CA4BDE55A59E0DM6PR03MB4731namp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/i7tcfgqHuK18L7VG47GSYoGf3QI>
Subject: Re: [stir] quoted ppt parameter value redux
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 04 Oct 2019 20:39:47 -0000

I suggest some “backward compatibility awareness” in this decision:

i- Current RFC8224 Identity header syntax allows both quoted/unquoted values for ppt as it is defined as a “token”.
ii- Current RFC8224 4.1 seems to imply that Identity header ppt value is expected to be unquoted as it asks to quote the ppt parameter value when construction the ppt JSON key.

Now, we want to enforce the opposite. This may cause issues with existing equipment which is implemented according to i-/ii-. Some would be lenient, some would expect unquoted and some maybe would expect quoted. I suggest that errata provides clarification that:

 *   Both forms are valid
 *   Quoting of ppt JSON key should happen only if the ppt parameter value is not quoted

It would be better to enforce a single format from day one but alas… For now, I think enforcing leniency is the least worst of possible options.

Thanks,
Tolga

From: stir <stir-bounces@ietf.org> On Behalf Of Subir Das
Sent: Thursday, October 3, 2019 5:09 PM
To: Chris Wendt <chris-ietf@chriswendt.net>
Cc: Peterson, Jon <jon.peterson@team.neustar>; stir@ietf.org
Subject: Re: [stir] quoted ppt parameter value redux

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

I also agree that we should stick to that decision.

-Subir

On Thu, Oct 3, 2019 at 4:20 PM Chris Wendt <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>> wrote:
Yes, i think we should stick with that decision, if other parameters are quoted, it only makes sense ppt should be as well.

Let’s do an errata on this.

-Chris

> On Oct 3, 2019, at 1:27 PM, Peterson, Jon <jon.peterson@team.neustar<mailto:jon.peterson@team.neustar>> wrote:
>
>
> RFC8224 section 4.1 gives the following guidance about the syntax for PASSporT Types:
>
>      Fourth, if a PASSporT extension is in use, then the optional JSON
>      key "ppt" MUST be present and have a value equivalent to the
>      quoted value of the "ppt" parameter of the Identity header field.
>
> Does that imply that the values of the "ppt" parameter in the Identity header field are quoted? If so, that seems to create a conflict with the ABNF for the Identity header field, which gives "token" as the type for "ppt" parameter values.  Back in IETF 101, as we were pushing along the first PASSporT types as extensions to STIR, "div" and "rph", we had a discussion about whether the values of the "ppt" parameter of the Identity header should be quoted or unquoted. As we said at the time, it isn't really important whether ppt parameter values are quoted or not from a design perspective, but It is important that we all just agree on it one way or another. The outcome of that discussion was reflected in the minutes as:
>
>   ISSUE: Should ppt values be quoted or not?
>   OUTCOME: Quoting is mandatory.
>
> Based on that outcome, we baked quoted ppts into the resulting docs (see RFC8443 4.1 for an example with ppt="rph" rather than ppt=rph). However, as STIR implementation ramps up, we are hearing a number of reports of AS's using unquoted ppt parameter values, and it sounds like many VS implementations are resigned to accepting both - but that some implementations are only accepting unquoted.
>
> We have the opportunity to errata RFC8224 to set this matter straight, but it seems the implementation community still doesn't agree on what should count as straight. Unquoted saves two octets, but let's be honest, saving two octets of a STIR Identity header field value, especially one with a PASSporT extension, is not going to let anyone fall back to UDP. Quoted conforms with what's in RFCs we've already shipped, and ones in the pipeline. I hate to re-open a discussion we had already, but it does seem to be necessary. If we’re going to errata this, should the fix conform to the IETF 101 consensus call ("quoting is mandatory") or not?
>
> Jon Peterson
> Neustar, Inc.
>
> _______________________________________________
> stir mailing list
> stir@ietf.org<mailto:stir@ietf.org>
> https://www.ietf.org/mailman/listinfo/stir<https://www.ietf.org/mailman/listinfo/stir>

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


-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------