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

Roman Shpount <roman@telurix.com> Tue, 20 April 2021 17:48 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 A85D83A0EE6 for <stir@ietfa.amsl.com>; Tue, 20 Apr 2021 10:48:07 -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 TD-LR64Vb0Ns for <stir@ietfa.amsl.com>; Tue, 20 Apr 2021 10:48:01 -0700 (PDT)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 F01E83A0EDA for <stir@ietf.org>; Tue, 20 Apr 2021 10:48:00 -0700 (PDT)
Received: by mail-qv1-xf35.google.com with SMTP id j3so19014080qvs.1 for <stir@ietf.org>; Tue, 20 Apr 2021 10:48:00 -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=8bGVtHfsKXhi/aoPLJ/4F2kIydGV6eyRRuzZ150sFlo=; b=eMeRNoSbOV1VJDRmI7GwgDqYykbsSANHDc+1Xo6bePSIWgVQOZNk4/Iw5zm2FsqLfS 2zq+pwJZN8y31Ld2xyb2b1FVB1CsRUxEky493v8C6ZpqKdzgMgjLn3jhB/PheEOx7OTU 55UiM1Y1gjk6YDfc8E2zAa7Xk6qsE6Fp3jUxHv/iFDcAooHJbCgaga3FcRnJpfkvPn7b F/MKmJiTOBevybg2cUe1NTVrKO0urEuRsZ4hyWG+DmNQ4zDjfXWQGd3vdXZqJZNC93h8 w/s5prVlb1k0cnkVy+vHpGP+WGs58B9apy+Ss7w9M5hORVZkNdLJ8Z0AWCqEIUmkU9st xEsw==
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=8bGVtHfsKXhi/aoPLJ/4F2kIydGV6eyRRuzZ150sFlo=; b=MqsPoKaX4Equ5xYbtDQvPfyU/IDZXugMnpt8ntGALBejsU3Z1x/b7YE0OQqVVzBuKZ C1aqHeOdAnmpzh0lg2Qa4zdDgib2N9DUqZE5WpYUc66u9m6tVDXZnAPP4198NxovWBWW mdUMkAHDddjl1T3kikQNErSboJvq+U9UT8KtaPnybIKNSWJwSCnX+FLTRFdI34/nNhOy uYBxzlIYegUaOqCPh8mC2h2OT/BBpcxASXQtpj+H8TjAO4P2Y6fMM3wuzzdKuRORFbla bu69NCBLXKbUOpuMk2P+13gg9nvLRQ+o7hFHWALT7y6piAjNmHV3pdrvdQ4MTP+lO3es p/yg==
X-Gm-Message-State: AOAM532CWGFheyC4eVW1qW5CI2smVZb2lahjOQMi7IfIWD5+oqNjSfLm 9g3ZqjvNePChULAUZ7mAUiCeARtWtRlsbQ==
X-Google-Smtp-Source: ABdhPJxpB5Zk1r/qmbOm9Z00z8kR1VH7mmybZvkuIChSJBrBrvSdzwc7+0tGDTm6g0tzrdFtnUuA/w==
X-Received: by 2002:a0c:f18c:: with SMTP id m12mr28054179qvl.19.1618940878400; Tue, 20 Apr 2021 10:47:58 -0700 (PDT)
Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com. [209.85.219.171]) by smtp.gmail.com with ESMTPSA id a187sm12515023qkd.69.2021.04.20.10.47.57 for <stir@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Apr 2021 10:47:57 -0700 (PDT)
Received: by mail-yb1-f171.google.com with SMTP id c195so43970934ybf.9 for <stir@ietf.org>; Tue, 20 Apr 2021 10:47:57 -0700 (PDT)
X-Received: by 2002:a25:5883:: with SMTP id m125mr25526855ybb.171.1618940877331; Tue, 20 Apr 2021 10:47:57 -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> <CAD5OKxuwB=VxjcJ6LRboHTY5evQap9k-g=M+L8OQChPDdt3BFQ@mail.gmail.com> <BN6PR11MB392155D7F465C334B96DB92199489@BN6PR11MB3921.namprd11.prod.outlook.com> <CAD5OKxvdgOzvcgc6DMN6_kpL0bsdXu8EnGzCxSqhAhKGeqiiPw@mail.gmail.com> <BN6PR11MB3921FF3AE658E7FAEB8DCE1F99489@BN6PR11MB3921.namprd11.prod.outlook.com>
In-Reply-To: <BN6PR11MB3921FF3AE658E7FAEB8DCE1F99489@BN6PR11MB3921.namprd11.prod.outlook.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 20 Apr 2021 13:47:45 -0400
X-Gmail-Original-Message-ID: <CAD5OKxsUDarfzV3-Bo9e9Zvt7pj=0fLmaE5n4a0X8Scu2kvpvg@mail.gmail.com>
Message-ID: <CAD5OKxsUDarfzV3-Bo9e9Zvt7pj=0fLmaE5n4a0X8Scu2kvpvg@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="000000000000e7e20a05c06b0b1d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/JTiyQExBIM2RyWm03DudMbnQigI>
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 17:48:08 -0000

Hi Alec,

In https://tools.ietf.org/html/rfc8224#section-6.1 Step 3:

An authentication service MUST add a Date header field to SIP requests that
do not have one.

Best Regards,
_____________
Roman Shpount


On Tue, Apr 20, 2021 at 1:44 PM Alec Fenichel <alec.fenichel@transnexus.com>
wrote:

> Roman,
>
>
>
> Is there text that I missed that makes the Date header required?
>
>
>
> Let me rephrase my first proposed change:
>
>
>
>    1. The document should be prescriptive about whether quotes are
>    required around the ppt parameter value or not
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> Senior Software Architect
>
> alec.fenichel@transnexus.com
>
> +1 (407) 760-0036
>
> TransNexus
>
>
>
> *From: *Roman Shpount <roman@telurix.com>
> *Date: *Tuesday, April 20, 2021 at 13:40
> *To: *Alec Fenichel <alec.fenichel@transnexus.com>
> *Cc: *Peterson, Jon <jon.peterson=40team.neustar@dmarc.ietf.org>rg>,
> Peterson, Jon <jon.peterson@team.neustar>ar>, Marc Petit-Huguenin <
> marc@petit-huguenin.org>gt;, IETF STIR Mail List <stir@ietf.org>rg>, Russ
> Housley <housley@vigilsec.com>om>, Christer Holmberg <
> christer.holmberg@ericsson.com>
> *Subject: *Re: [stir] Proposal for update of erratum #6519
>
> Alec,
>
>
>
> I would also like to add:
>
>
>
> 1. The Date header should be optional when full PASSporT is used. The iat
> in PASSporT should provide enough protection for cut-and-paste attacks.
>
> 2. I think privacy considerations should be added that recommend using
> SIPS since the data carried in PASSporT is likely considered personally
> identifiable information and should not be transmitted in encrypted form.
>
>
>
> Still, I wouldn't say I like quotes around the ppt param value since this
> parameter differs from every other token parameter in SIP headers.
>
> _____________
> Roman Shpount
>
>
>
>
>
> On Tue, Apr 20, 2021 at 12:33 PM Alec Fenichel <
> alec.fenichel@transnexus.com> wrote:
>
> Roman,
>
>
>
> Makes sense. I think a new version would be great. Proposed changes:
>
>
>
>    1. Require quotes around ppt param value
>    2. Make info param optional when using full form PASSporTs to make OOB
>    easier for transit providers
>    3. Allow info param to match claims other than x5u (e.g., jku, etc.)
>    to support DLT and other future PASSporT extensions that don’t use x5u
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> Senior Software Architect
>
> alec.fenichel@transnexus.com
>
> +1 (407) 760-0036
>
> TransNexus
>
>
>
> *From: *Roman Shpount <roman@telurix.com>
> *Date: *Tuesday, April 20, 2021 at 12:02
> *To: *Alec Fenichel <alec.fenichel@transnexus.com>
> *Cc: *Peterson, Jon <jon.peterson=40team.neustar@dmarc.ietf.org>rg>,
> Peterson, Jon <jon.peterson@team.neustar>ar>, Marc Petit-Huguenin <
> marc@petit-huguenin.org>gt;, IETF STIR Mail List <stir@ietf.org>rg>, Russ
> Housley <housley@vigilsec.com>om>, Christer Holmberg <
> christer.holmberg@ericsson.com>
> *Subject: *Re: [stir] Proposal for update of erratum #6519
>
> 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.
>
>