Re: [stir] Roman Danyliw's Discuss on draft-ietf-stir-passport-divert-08: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Jon!

Thanks for the explanations below and the updated text in -09.  It addresses my concerns and I will clear my ballot.

Regards,
Roman

> -----Original Message-----
> From: Peterson, Jon <[e-mail]>
> Sent: Monday, July 13, 2020 10:42 AM
> To: Roman Danyliw <[e-mail]>rg>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Russ Housley <[e-mail]>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-stir-passport-divert-08:
> (with DISCUSS and COMMENT)
> 
> 
> Hi Roman,
> 
> Thanks for the notes on this; sorry for taking a while to get around to them.
> 
>     Roman Danyliw has entered the following ballot position for
>     draft-ietf-stir-passport-divert-08: Discuss
> 
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
> 
>     Section 5.  The text notes that procedures for the authentication and
>     verification service for the “div-o” claim will be “left to future work”.  Can
>     the rational for this deferral be explained.  Creating an interoperable
>     solution without this guidance seem challenging as it would be crucial
> guidance
>     on processing this newly introduced claim.
> 
> This -08 text mostly resulted from a process matter. To get into the document
> history a bit, when we moved stir-oob off the Standards Track to an
> Informational in the late stages of its development, we still wanted "div" to be
> future-proof when/if standards-track work based on the OOB framework rolled
> around (like for example the new OOB servprovider draft in STIR). Our solution
> was to uplevel: to specify "div-o" as something not specifically coupled to OOB,
> but instead as a general mechanism that could be used by OOB or other
> protocols that might prefer to use nested "div-o" style PASSporTs. That isn't an
> entirely cynical move, as we anticipate that protocols other than SIP will use
> the PASSporT mechanism, and might want to use the nested approach of "div-
> o".
> 
> I think within those constraints, I can thread the needle with some useful text
> about the non-SIP AS/VS behavior associated with the creation of "div-o"
> PASSporTs in a way that makes no explicit reference to OOB as such, but would
> apply equally if say XMPP or RTCWeb or some similar mechanism wanted to
> make use of PASSporT and nested "div". I've added some text to this effect,
> which I hope is sufficient - let me know if it isn't.
> 
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
> 
>     Please respond to Phillip Hallam-Baker SECDIR review (thanks Phillip!)
> 
> Done.
> 
>     ** Section 4.1.  Per “Provided that these PASSporTs share the same "orig"
> and
>     "dest" values, the retargeting entity's authentication service SHOULD
> generate
>     only one "div" PASSporT”, why not  MUST here?  What’s the corner case?
> 
> One corner case I can imagine is where diverts from special-use PASSporTs need
> to be signed with a certificate issued by a one-off trust anchor. Say, due to the
> government policy constraints of the "rph" header or something similar, you
> need to sign a "div" for its PASSporT with a different credential than you would
> use to sign a "div" for ordinary carrier calls. Not a common case, but, I don't
> want to close the door on it.
> 
>     ** Section 4.2.  Per “However, note that in some use cases, including  certain
>     ways that blind transfer is implemented, it is possible that an established
>     call will be retargeted long after it has originally been placed, and
>     verification services may want to allow a longer window for the freshness of
>     the innermost PASSporT if the call is transferred from a trusted party.”, are
>     there any recommendations or bounds that can be placed on the duration of
> this
>     “longer window of freshness”?
> 
> Unfortunately, not ones that are immensely useful - maybe like 3 hours?
> Attended transfer services can be triggered any time into a call - if you've ever
> gone through escalation with a bank company customer service line, you've
> probably experienced multiple such transfers during a single call which begins
> with you being on hold for 45 minutes, and you can easily spend ten minutes
> talking to one agent before you end up on the line with another. I think the
> "trusted party" portion here is the significant bit - that relying parties should
> only accept these kinds of stale PASSporTs within a closed circle of trust. Still,
> calls don't last for like a week, so there must be some upper bound here. I can
> put in 3 hours as a soft recommendation, I guess, if it helps...
> 
>     ** Editorial Nit:
> 
>     -- Section 3. Typo. s/identifiier/identifier/
> 
> Fixed. Thanks!
> 
> Jon Peterson
> Neustar, Inc.
> 
> 
> 
>