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

From: Robert Sparks <[email-masked]>
Date: Tue, 8 Dec 2020 15:30:55 -0600

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 10 Dec 2020 18:17:17 -0500

The Abstract seems a bit long.  I think these points belong in the Abstract:

  - Extends PASSporT from RFC 8225 to include RCD
  - Extend caller and call specific information beyond human-readable display
   name comparable to the telephone network "Caller ID"
 - RCD is extensible
 - RCD when coupled with STIR provides signature over the information
 - RCD can also be used with SIP Call-Info

General: This appears many times: "Rich Call Data (RCD)".  Once in the Introduction should be enough.

Section 2: Ha ha. Please use:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Section 3: "Additionally, [I-D.ietf-sipcore-callinfo-rcd] also ..."  Please drop "also".

Section 5.1: What does "default" mean?  I think you mean that this is the inital set of keys, and more can be added in the future.

Section 5.1.4: Please add a reference to:

   [SHS]      National Institute of Standards and Technology (NIST),
              "Secure Hash Standard", FIPS Publication 180-4, August
              2015.

Also, I I suggest a bit or rewording::

   implementations MUST support the SHA-256, SHA-384, and SHA-512 hash algorithms [SHS].

Finally, if other hash algorithms MAY be supported, do we need an IANA registry for the strings associated with the other algorithms?

Section 6.1: Clearly the phone number should be 1-202-555-0007 ...

Russ

> On Dec 8, 2020, at 4:30 PM, Robert Sparks <[email-masked]> wrote:
> 
> If you plan to provide a review but need more time, please let us know early.
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Jack Rickard <[email-masked]>
Date: Tue, 15 Dec 2020 15:32:00 +0000

Comments:
Section 9.1: Is the "iss" claim meaning specified anywhere else? This part reads like it is referencing some existing behaviour but I am unable to find anything defining it. I ask because this doesn't feel like it should be specific to this standard and would be useful for, for example, RPH where the cert identifies the source of the prioritisation.

Section 9.1: "the value of "iss" however MUST reflect the Subject Name field" is unclear, the "MUST" is very strong but the "reflect" very vague, should it equal it? If so in what format? I'm also not sure why this is useful, you will already have the subject name of the certificate, as you have to have the certificate to verify the signature.

Section 10: How should the passport indicate the relationship of the generator of the PASSporT to the caller? In the first party case I think you've left this entirely unspecified, and in the third party case that is not how "iss" was defined in the previous section, and it isn't clear how you would go from a third party organisation name to their relationship with the caller.

Section 5.1.5: The example isn't a valid base64 string (due to the # and *), as JWT's use the URL safe variant of base64 encoding with no padding, it would be useful to clarify here which flavour of base64 encoding is being used.

Nits:
Section 6: I believe "The value of "rcd" is an array of JSON objects" is wrong here, it's a JSON object containing the "name" field, etc.

Section 8: The phrase "potential values of the "rcd" array" is also wrong, this isn't an array, something like "potential fields in the "rcd" claim" would be clearer.

Section 11.1: the example identity here isn't valid, I think it should have ".." preceeding the PASSport and no trailing "=".

Thanks,
Jack

-----Original Message-----
From: stir <[email-masked]> On Behalf Of Robert Sparks
Sent: 08 December 2020 21:31
To: [email-masked]
Subject: [stir] WGLC: draft-ietf-stir-passport-rcd-09

NOTE: Message is from an external sender

See <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-stir-passport-rcd%2F&amp;data=04%7C01%7Cjack.rickard%40metaswitch.com%7C19f85464b15848e0637d08d89bc098dd%7C9d9e56ebf6134ddbb27bbfcdf14b2cdb%7C1%7C0%7C637430598808552589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8Zz%2B%2BN10JP6zy4jaozXYqMqRwOdE%2BD1Om7A8Xr7SPMc%3D&amp;reserved=0>

RjS

_______________________________________________
stir mailing list
[email-masked]
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&amp;data=04%7C01%7Cjack.rickard%40metaswitch.com%7C19f85464b15848e0637d08d89bc098dd%7C9d9e56ebf6134ddbb27bbfcdf14b2cdb%7C1%7C0%7C637430598808552589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=UmjwL7Iy4LKkqdwlMD%2Fwlmbyl5ZvhqIM7ysOkO9Gnlc%3D&amp;reserved=0

---

From: Ben Campbell <[email-masked]>
Date: Thu, 17 Dec 2020 22:11:00 -0600

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 <[email-masked]> wrote:
>