Re: [stir] WGLC: draft-ietf-stir-passport-rcd-09

[Ben Campbell <[e-mail]>]

Hi,

I like this draft a lot, but I do have some WGLC comments. Apologies if these rehash old discussions; I’m feeling sort of stateless this season ;-)

Thanks!

Ben.

---------------

*** Substantive Comments ***

- General: 

— I think this draft needs some early explanation of what it means for someone (first-party or third-party) being authoritative for some or all of the RCD associated with a call. The draft references this concept many times, but I think there are some architectural assumptions that may not be obvious to everyone, especially those not exposed to the politics around who controls what gets displayed to a call recipient.. (Chris’s SIPNOC presentation might have some helpful ideas here.)

— I’m a bit confused about when the rcdi JWT constraints are required or optional (more specifics below.)

- §1, last paragraph: " 
This document furthermore specifies a third-party profile that would allow
   external authorities to convey rich information associated with a
   calling number via a new type of PASSporT”

Are we talking about ppt=rcd, or something else? Does this suggest the use of RCD passports (as opposed to other passports with RCD claims) are not intended for first-party assertions?

- §5.1.1: "If there is no string associated with a display name, the claim value SHOULD then be an empty string.”

Why SHOULD, not MUST (or maybe just “is”)? Can we foresee some situation where something other than an empty string might be appropriate?

- §5.1.1, §5.1.2, and §5.1.2: Each of these sections talks about deriving data from certain SIP header fields. Nam from the From: display name, jcd/jcl from Call-Info. But the language around that derivation is different in each section in a way that might be read to have different strengths (e.g. “for example”, “is intended to represent” and  “may derive from”. It would be helpful to be consistent and clear about how important it is for the RCD to match the related SIP header fields.

- §5.1.4: "The "rcdi" claim is an optional claim that SHOULD be included if the application requires integrity to be applied to the content of the "rcd” claim”

I’m confused by the global SHOULD here. For example, if I am including an RCD passport with no external content and no third-party policy control, why would I need rcdi? Maybe that is not a legitimate use case? 


- §5.1.5 (and possibly Security Considerations): 

In order to sign and verify RCD passports that have links to external data, one has to retrieve the target for each link. And if those links lead to other links, this must be recursive. Is there a potential for this to be used for a DoS (or other sorts of) attack? In particular, it seems like the draft needs some guidance about sanity checking things for crazy-large targets, long or looping link chains, etc. In particular, the VS needs to do this before verifying the signature, so it cannot be sure that the RCD should be trusted prior to retrieving the content.

- §5.1.6: 
-- This section can be read to say the issuer must always include the JWT Contraints to require rcdi. Is that the intent? In either case, some clarification of the normative language would be helpful. (e.g. maybe you MAY include the constraints, but if you do you MUST do…

-- Is there a use case where a CA might require the integrity mechanism to be used, but not require any specific value? (e.g. “mustInclude” rcdi, but no “permittedValue”?)

- §6.1.1, last example: "If we were to add a "rcdi" integrity claim to the last example…”

That example has external content. That makes “rcdi” a MUST. Isn’t the preceding example invalid due to not having rcdi?

- §8: “...hyperlinks to images, such as logos or pictures of faces, or to similar external profile information…"

I may be confused on this point, but aren’t those already supported in jCard? And in general, how does the new registry here interact with the existing jCard/vCard extension mechanism(s)?

- §9: 
-- General: The distinction between first-party and third-party passports seems a bit fuzzy. For example, does an STI-AS inserted SHAKEN passport that has RCD claims count as a first-party or third-party passport? What about a SHAKEN or RCD passport inserted by a tdm->SIP gateway in an OOB deployment?

-- "If the display name in the "rcd" PASSporT object matches the display name in the INVITE, then the name would presumably be rendered to the end user by the terminating user agent.”

That match is not a requirement for first-party RCD passports, is it? Why would it be different for third-party ones?

- §9.1: " A third-party PASSporT, which contains such an "iss” element…”

This is the first mention of “iss” elements in the draft. The wording “such an “iss” element” makes me wonder if there is some prior text messing that might have defined “third-party PASSporTs” in terms “iss”?

- §10: " Therefore, PASSporTs that carry “rcd" data SHOULD also carry an indication of the relationship of the generator of the PASSporT to the caller..”

Is that true for first-party RCD passports, or just third-party?

- §11.2: 

-- General: This section could use some guidance for VS behavior if the RCD in a passport conflicts with the respective SIP headers. I think the answer is to prefer the passport RCD if you trust it, for whatever definition of “trusting it’ you have. Would it ever make sense to prefer the unauthenticated SIP header field contents to the contents of a verified passport?

-- " If the PASSporT is in compact form, then the verification service SHOULD
   extract the display-name from the From header field value…”

Why not MUST? If this is indeed a SHOULD, it seems like that sort of SHOULD that needs some guidance about when it might be reasonable to do something different.

*** Editorial Comments ***

- Abstract:
-- “ This framework is intended to extend caller and call specific information beyond human-readable display name comparable to the "Caller ID" function common on the telephone network."

Not clear if the framework is comparable or the human readable name is comparable. I assume the second.

- Introduction:
-- Please expand PASSporT on first use.
-- Please expand JWT on first use.
-- Please expand STIR on first use.

- §6: “… any entities verifying the PASSporT object will be required to understand the "ppt" extension in  order to process the PASSporT in question.”

Should that be the “rcd” extension?

- §6.1,  first paragraph: s/obejct/object

- §8, last paragraph: Seems like this paragraph belongs in §9.


> On Dec 8, 2020, at 3:30 PM, Robert Sparks <[e-mail]> wrote:
> 
> This is a WGLC for draft-ietf-stir-passport-rcd-09.
> 
> Please send reviews to the list by the end of day 22 Dec 2020.
> 
> If you plan to provide a review but need more time, please let us know early.
> 
> See <https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/>
> 
> RjS
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir