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

[Roman Shpount <[e-mail]>]

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 <[e-mail]>
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
>
> [e-mail]
>
> [phone]
>
> TransNexus
>
>
>
> *From: *Roman Shpount <[e-mail]>
> *Date: *Tuesday, April 20, 2021 at 13:40
> *To: *Alec Fenichel <[e-mail]>
> *Cc: *Peterson, Jon <jon.peterson=[e-mail]>,
> Peterson, Jon <[e-mail]>, Marc Petit-Huguenin <
> [e-mail]>, IETF STIR Mail List <[e-mail]>, Russ
> Housley <[e-mail]>, Christer Holmberg <
> [e-mail]>
> *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 <
> [e-mail]> 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
>
> [e-mail]
>
> [phone]
>
> TransNexus
>
>
>
> *From: *Roman Shpount <[e-mail]>
> *Date: *Tuesday, April 20, 2021 at 12:02
> *To: *Alec Fenichel <[e-mail]>
> *Cc: *Peterson, Jon <jon.peterson=[e-mail]>,
> Peterson, Jon <[e-mail]>, Marc Petit-Huguenin <
> [e-mail]>, IETF STIR Mail List <[e-mail]>, Russ
> Housley <[e-mail]>, Christer Holmberg <
> [e-mail]>
> *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 <
> [e-mail]> 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
>
> [e-mail]
>
> [phone]
>
> TransNexus
>
>
>
> *From: *Peterson, Jon <jon.peterson=[e-mail]>
> *Date: *Tuesday, April 20, 2021 at 11:05
> *To: *Alec Fenichel <[e-mail]>, Peterson, Jon
> <[e-mail]>, Roman Shpount <[e-mail]>, Marc
> Petit-Huguenin <[e-mail]>
> *Cc: *IETF STIR Mail List <[e-mail]>, Russ Housley <
> [e-mail]>, Christer Holmberg <[e-mail]>
> *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 <[e-mail]> on behalf of Alec Fenichel
> <alec.fenichel=[e-mail]>
> *Date: *Tuesday, April 20, 2021 at 7:59 AM
> *To: *"Peterson, Jon" <jon.peterson=[e-mail]>, Roman
> Shpount <[e-mail]>, Marc Petit-Huguenin <[e-mail]>
> *Cc: *IETF STIR Mail List <[e-mail]>, Russ Housley <
> [e-mail]>, Christer Holmberg <[e-mail]>
> *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
>
> [e-mail]
>
> [phone]
>
> TransNexus
>
>
>
> *From: *stir <[e-mail]> on behalf of Peterson, Jon
> <jon.peterson=[e-mail]>
> *Date: *Tuesday, April 20, 2021 at 10:47
> *To: *Roman Shpount <[e-mail]>, Marc Petit-Huguenin <
> [e-mail]>
> *Cc: *IETF STIR Mail List <[e-mail]>, Russ Housley <
> [e-mail]>, Christer Holmberg <[e-mail]>
> *Subject: *Re: [stir] Proposal for update of erratum #6519
>
>
>
> Inline.
>
>
>
> *From: *stir <[e-mail]> on behalf of Roman Shpount <
> [e-mail]>
> *Date: *Monday, April 19, 2021 at 6:57 PM
> *To: *Marc Petit-Huguenin <[e-mail]>
> *Cc: *IETF STIR Mail List <[e-mail]>, Russ Housley <
> [e-mail]>, Christer Holmberg <[e-mail]>
> *Subject: *Re: [stir] Proposal for update of erratum #6519
>
>
>
> On Mon, Apr 19, 2021 at 7:56 PM Marc Petit-Huguenin <
> [e-mail]> 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.
>
>