Re: [stir] Proposal for update of erratum #6519

Roman Shpount <roman@telurix.com> Tue, 20 April 2021 16:02 UTC

Return-Path: <roman@telurix.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 AA2E83A2944 for <stir@ietfa.amsl.com>; Tue, 20 Apr 2021 09:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 CkrvgUuKjxSu for <stir@ietfa.amsl.com>; Tue, 20 Apr 2021 09:02:41 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 41B3C3A293F for <stir@ietf.org>; Tue, 20 Apr 2021 09:02:40 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id q4so673615qtn.5 for <stir@ietf.org>; Tue, 20 Apr 2021 09:02:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tvcCCxFJdogRz8I1SAd4TsMTfM9aXqHQXUTUpDRmqAo=; b=195bY9CKyFyocvj11J35rpHKL7oOw0Ujy8LcLv954mTlJ8wYKqmZRFh/QGdCnwmO5s mpVF2mx77PlL9hRugiIWXisEeTblYDkmXb1oR7cs0KUwWl3czOluwy3GpZh646AHRGRe ZNvElr8Vb6VCOy/GpbZ77PM2VbVyQ857B6NxOn/Oebf3+nDRuHXq/NV1177jfRIKHJAF P80euVzYA/omCkG7POCsu9U+cSGL++U9Um1QGT7W+ShjvxnQe6LvJZYFPoTVGkR+1aSE rTc/ksin5N0+vZiuVZTyweWQ0UYFq0+Xw/QpElKVdJsZKOlXR3uCf7rVJiiN8esn6k9W K1UQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tvcCCxFJdogRz8I1SAd4TsMTfM9aXqHQXUTUpDRmqAo=; b=bY7Zh5HkU+TlRmNvM2aFndTpUG8TjzcLOACc6LjIJ+0dxKc57ZBPyUjHnqd9Qd6b46 Hqdbyl7KEqMzIbD8aONfQuKMOZg4WgeB9oTO9PUKctrR0H645Kpu/dmEMlYbijueYS2M U28Kafp3qXkaPy5s0UXyid1nuQtiWPrss1+7M8xZzgAwHxuyVKpb+o5liuhBko+MxI3K 7rwQ3qSppMUCYhCfJT3j4RMaQK+4DLOplPqT3eLd+nnHEjGOuAemCCDBCdoYoJObHjL4 XASE/EljSzcSMWkgXZN2N2t0y8hSW5QOP+SmOhaekTWa5bposjbEwHpugvAXWsz1O1d8 JfIw==
X-Gm-Message-State: AOAM530S3pNascrQVccVRNmskz+00Fvoo+AJGqQUMVOOckhvWg/PHu9O haiaAH7r9TMDMaK6heHt/yVlRwXzHpdnbw==
X-Google-Smtp-Source: ABdhPJxSaqW490cfuTlNKWPRYN+vgdv8ubJtHPRX5vq7HHSeNFu85XzeSVA/xbvZex6WZ53Q+RoNgQ==
X-Received: by 2002:ac8:698d:: with SMTP id o13mr17713009qtq.203.1618934558197; Tue, 20 Apr 2021 09:02:38 -0700 (PDT)
Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com. [209.85.219.178]) by smtp.gmail.com with ESMTPSA id p145sm1607566qke.67.2021.04.20.09.02.37 for <stir@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Apr 2021 09:02:37 -0700 (PDT)
Received: by mail-yb1-f178.google.com with SMTP id 65so43609035ybc.4 for <stir@ietf.org>; Tue, 20 Apr 2021 09:02:37 -0700 (PDT)
X-Received: by 2002:a25:943:: with SMTP id u3mr26489273ybm.489.1618934557050; Tue, 20 Apr 2021 09:02:37 -0700 (PDT)
MIME-Version: 1.0
References: <42e964d3-2a16-660b-f8b4-fd9daedad115@petit-huguenin.org> <AM0PR07MB38604255784FF9E621257B2D93499@AM0PR07MB3860.eurprd07.prod.outlook.com> <3d8e2fce-d124-99b9-e295-734a36ad564a@petit-huguenin.org> <7558AA11-A7F9-4091-BFD3-F42C742AABAE@vigilsec.com> <167dde10-f242-2b6f-a7ce-96991158589a@petit-huguenin.org> <CAD5OKxvkN+BSY0XuBmfApDDWOLhqCLLFuQgVQryE+yHUftWs4w@mail.gmail.com> <15fc4a20-b5c8-cd27-b30e-76e1f479b4ff@petit-huguenin.org> <CAD5OKxvmvmotpxB8BGJfqRrVTjEGKQkQRow37gmwRMFaBGjEoA@mail.gmail.com> <DF470A3C-6033-48F4-8A61-3442C5DD2239@team.neustar> <BN6PR11MB39216109781BE5DE5C35AB6399489@BN6PR11MB3921.namprd11.prod.outlook.com> <6F5317AE-44F5-4CAA-82B8-830FF5223179@team.neustar> <BN6PR11MB3921A7E9996332ED9E057E4C99489@BN6PR11MB3921.namprd11.prod.outlook.com>
In-Reply-To: <BN6PR11MB3921A7E9996332ED9E057E4C99489@BN6PR11MB3921.namprd11.prod.outlook.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 20 Apr 2021 12:02:25 -0400
X-Gmail-Original-Message-ID: <CAD5OKxuwB=VxjcJ6LRboHTY5evQap9k-g=M+L8OQChPDdt3BFQ@mail.gmail.com>
Message-ID: <CAD5OKxuwB=VxjcJ6LRboHTY5evQap9k-g=M+L8OQChPDdt3BFQ@mail.gmail.com>
To: Alec Fenichel <alec.fenichel@transnexus.com>
Cc: "Peterson, Jon" <jon.peterson=40team.neustar@dmarc.ietf.org>, "Peterson, Jon" <jon.peterson@team.neustar>, Marc Petit-Huguenin <marc@petit-huguenin.org>, IETF STIR Mail List <stir@ietf.org>, Russ Housley <housley@vigilsec.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="000000000000300d7e05c069939e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/hYjHJU4YB7bQ-Y2FO5eG4N-O8Jc>
Subject: Re: [stir] Proposal for update of erratum #6519
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: Tue, 20 Apr 2021 16:02:48 -0000

Alec,

My personal opinion is that we should try to organize an open SipIt interop
event for both STIR and SHAKEN implementations. Based on the interop
results, it might be good to do a new version of RFC 8224.

Meanwhile, we really need this errata so that we can deal with current
interop issues.

Best Regards,
_____________
Roman Shpount


On Tue, Apr 20, 2021 at 11:31 AM Alec Fenichel <alec.fenichel@transnexus.com>
wrote:

> Jon,
>
>
>
> Understood. Then maybe we could just leave it as is until RFC 8224 is
> updated? Is there any implementation out there that doesn’t support
> receiving with or without quotes?
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> Senior Software Architect
>
> alec.fenichel@transnexus.com
>
> +1 (407) 760-0036
>
> TransNexus
>
>
>
> *From: *Peterson, Jon <jon.peterson=40team.neustar@dmarc.ietf.org>
> *Date: *Tuesday, April 20, 2021 at 11:05
> *To: *Alec Fenichel <alec.fenichel@transnexus.com>om>, Peterson, Jon
> <jon.peterson@team.neustar>ar>, Roman Shpount <roman@telurix.com>om>, Marc
> Petit-Huguenin <marc@petit-huguenin.org>
> *Cc: *IETF STIR Mail List <stir@ietf.org>rg>, Russ Housley <
> housley@vigilsec.com>gt;, Christer Holmberg <christer.holmberg@ericsson.com>
> *Subject: *Re: [stir] Proposal for update of erratum #6519
>
>
>
> I mean, no, it’s just pushy. It’s the same reason we don’t propose that
> you MUST only accept quoted. Given that it was the ambiguity in the
> original spec that caused this problem, I’m a little hesitant to be that
> pushy.
>
>
>
> Maybe for the errata we could be less pushy, but when we (inevitably,
> someday) do an actual update or bis to RFC8224, we could be more pushy
> about it.
>
>
>
> Jon Peterson
>
> Neustar, Inc.
>
>
>
> *From: *stir <stir-bounces@ietf.org> on behalf of Alec Fenichel
> <alec.fenichel=40transnexus.com@dmarc.ietf.org>
> *Date: *Tuesday, April 20, 2021 at 7:59 AM
> *To: *"Peterson, Jon" <jon.peterson=40team.neustar@dmarc.ietf.org>rg>, Roman
> Shpount <roman@telurix.com>om>, Marc Petit-Huguenin <marc@petit-huguenin.org>
> *Cc: *IETF STIR Mail List <stir@ietf.org>rg>, Russ Housley <
> housley@vigilsec.com>gt;, Christer Holmberg <christer.holmberg@ericsson.com>
> *Subject: *Re: [stir] Proposal for update of erratum #6519
>
>
>
> Is it really a problem to just say that you must (or must not, either way)
> include quotes and be done? STI-AS and STI-VS implementations will need to
> be updated frequently over the next few years due to all of the new
> PASSporT extensions, so expecting implementations to add/remove quotes
> seems reasonable. Implementations could accept both values at their
> discretion, even if it violates the standard.
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> Senior Software Architect
>
> alec.fenichel@transnexus.com
>
> +1 (407) 760-0036
>
> TransNexus
>
>
>
> *From: *stir <stir-bounces@ietf.org> on behalf of Peterson, Jon
> <jon.peterson=40team.neustar@dmarc.ietf.org>
> *Date: *Tuesday, April 20, 2021 at 10:47
> *To: *Roman Shpount <roman@telurix.com>om>, Marc Petit-Huguenin <
> marc@petit-huguenin.org>
> *Cc: *IETF STIR Mail List <stir@ietf.org>rg>, Russ Housley <
> housley@vigilsec.com>gt;, Christer Holmberg <christer.holmberg@ericsson.com>
> *Subject: *Re: [stir] Proposal for update of erratum #6519
>
>
>
> Inline.
>
>
>
> *From: *stir <stir-bounces@ietf.org> on behalf of Roman Shpount <
> roman@telurix.com>
> *Date: *Monday, April 19, 2021 at 6:57 PM
> *To: *Marc Petit-Huguenin <marc@petit-huguenin.org>
> *Cc: *IETF STIR Mail List <stir@ietf.org>rg>, Russ Housley <
> housley@vigilsec.com>gt;, Christer Holmberg <christer.holmberg@ericsson.com>
> *Subject: *Re: [stir] Proposal for update of erratum #6519
>
>
>
> On Mon, Apr 19, 2021 at 7:56 PM Marc Petit-Huguenin <
> marc@petit-huguenin.org> wrote:
>
> A literalist.  Fantastic.
>
>
>
> That was not my understanding.
>
>
>
> We can go back to the recording to check on the decision.
>
>
>
> More importantly, what is the normative strength of "be tolerant to the
> absence of quotes when receiving"? Is this MUST accept quotes? SHOULD
> accept quotes?
>
>
>
> In the sentence "Implementations SHOULD use quotes around the token when
> sending", what would be the valid use cases when implementations are
> allowed not to use quotes?
>
>
>
> My understanding is that SHOULD implies well know exceptions.
>
>
>
> The exception we are aware of is that implementations exhibiting this
> behavior exist. It is, in other words, for backwards compatibility reasons.
>
>
>
> Regardless of what the recording says (we were kinda all over the place,
> if I recall), I think I agree that the right semantics are that you MUST
> accept quoted and unquoted, and SHOUD send quotes (the exception to the
> SHOULD being backwards compatibility). If we said you MUST send quotes,
> well, then implementations that don’t are violating the spec. As you
> pointed out, it’s kind of a mixed bag at the moment out there in terms of
> where implementations are.
>
>
>
> Jon Peterson
>
> Neustar, Inc.
>