[stir] Thoughts on draft-ietf-stir-passport-rcd-04

[Eric Burger <[e-mail]>]

General:
The draft talks about “personal communications.” Is there anything ‘personal’ about the mechanism? Is there anything in the mechanism informed by the communications being personal? I was under the belief the main use case for this mechanism was enterprise communications. Am I mistaken?

General security issue:
Why would a terminating provider do a dip driven by the originator?
Why would we let a random caller ask a UAS to fetch a random URI? Issues here include:
 - Tracking
 - Malware
 - Detecting user presence (e.g., ignored a call that fetched the ‘logo’, versus blocked, versus …)

Section 3.2: icn
See general security issue above

Section 3.3: inf
See general security issue above, only multiplied because now we are interpreting generic HTML

Sections 3.4 / 3.5: jcd / icl
If I get both a jcd and a jcl, MUST I reject the call? If not, forever why not?
jcl has the general security issue.
Why not just have jcd as the mechanism?

Section 4.1: rcdi SHOULD vs MUST
Eric’s SHOULD construction is usually SHOULD X UNLESS Y, which by De Morgan’s theorem is better stated If Y MUST X.
Why is rcdi stated as “If the application requires integrity .. the rcd claim SHOULD …” as opposed to “If the application requires integrity .. the rcd claim MUST …” In plain English, the current wording says “If the application requires integrity, it really does not.”

Also, I think that requiring rcdi would help caching content, as one would not need to fetch anything to note the sender says the content is identical to the last time you saw it with the same rcdi.

Section 4.1: algorithms
Why do we list three hash algorithms to pick from? Unless there is a very compelling reason, please pick one. Having three mandatory to implements is begging for interoperability failure. If not interoperability failure, by increasing lines of code and code complexity, this is guaranteeing less secure code.

Section 4.1.1:
True curiosity on my part: since we’re using JWT, which preserves octet format of the source, why do we need to marshal anything? What does that buy us?

Section 6:
Since a jCard can have the logo, what is the value of a different icn claim? Why not just say the claim is a jCard?

Section 7:
Given the current state of third-party CNAM databases is a well-known source of evil, I’m wondering why we are not learning from the past and asking to recreate it now? I’m not doing a dig at one of the author’s affiliations: they are one of the (few? only?) CNAM database operators that is not on the take. However, there are a ton of much less expensive operators with less clear morals. In the world of Shockey’s Law, why would we go there again? Given the “present company excepted” nature of the comment, perhaps emphasizing the mechanism (does! yay!) have ways of rooting out bad actors will explain to the lay reader (or regulator) why third-party rcd is not evil squared.

While we’re there, we might note that the reason we say “*add* an Identity header” is this mechanism has the potential to be a MITM attack (by design). One could expect certain jurisdictions to ban wholesale replacement of the Identity header. However, that is beyond the scope of the IETF. On the other hand, it is why a third-party should not expect to replace the original Identity header if present or masquerade as putting on an original Identity header.

This really comes out in…

Section 10.1:
I would make clear there is no implicit trust in the veracity of the claims in an rcd. Unless the verification service has some reason to trust the claims, the claims are purely for entertainment purposes only.

Some reasons to trust the claims include, but are not limited to:
 - Business relationships between the rcd attester and verifier
 - Regulatory enforcement (e.g., the CSP is in a jurisdiction where lying has severe penalties)
 - Everything in the 3rd-party rcd attestation happens to line up with 1st-party signed attestations (e.g., name)


There are also a few typos. I’ll be happy to hand whomever wants them at the STIR WG meeting.