Re: [stir] Questions on the draft-ietf-stir-passport-rcd-04 integrity mechanism

[Eric Burger <[e-mail]>]

SHOULD works if there is a strong UNLESS.

In this case, the SHOULD is functionally equivalent to MAY. I do like Ben’s suggestion of “MAY use, MUST verify if present.” That is something actionable.

> On Sep 20, 2019, at 10:33 AM, Chris Wendt <[e-mail]> wrote:
> 
> We can talk on the call, but i think MAY seems a little too open ended to me.  I think high level there is three main levels of use-cases/security between use of “rcdi” and using JWT constraints.  I think i’d prefer to explicitly describe those scenarios, first not using “rcdi” at all, second using “rcdi” without constraints and then “rcdi” with constraints.  Does that make sense?
> 
> -Chris
> 
>> On Sep 16, 2019, at 5:41 PM, Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> 
>>> On Sep 13, 2019, at 12:17 PM, Peterson, Jon <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> 
>>> At a high level, what we want out of certs here is a capability that empowers the issuer of a certificate to constrain the contents of RCD when the signer signs a PASSporT. I don’t think we want to say that RCD can only be used when the JWT Constraint is present, and I don’t think we want to say that the integrity check provided by “rcdi” can only be present in a PASSporT when the signing certificate has a JWT Constraint in it. Including “rcdi” in the JWT Constraints should be just a hook, that the issuer of a certificate can use to make sure that RCD isn’t being abused in cases where there are concerns about that.
>> 
>> There’s nothing there I disagree with, but I don’t think that is quite what is captured in rcd-04.
>> 
>> Would it make sense to state the use of “rcdi” as MAY include and MUST verify if present.
>> 
>> 
>>> 
>>> Outside of the JWT Constraint, I was originally not immensely worried about link substitution attacks on the RCD system: that is, ones where the signer of an RCD PASSporT believes a URL in RCD points to an image of the Ford Motor Company, say, but while a SIP call is in transit, someone switches the resource that the URL indicates to an image of Chevrolet, so that when it is rendered on the terminating side the callee sees something different than the signer intended. The creator of the PASSporT, after all, picked that URL, and it just doesn’t make sense for them to pick a URL that they don’t have meaningful change control over. The only edge case where I see real concerns is one where the creator of the PASSporT and its signer are different administrative entities, and the creator tricks the signer into vouching for a URL that will be pointed to a different resource after it is signed. That edge case convinced me that there was at least some value to “rcdi” independent of the JWT Constraint; the “rcdi” lets the signer capture the resource as it was seen at signing time, which should help mitigate cases where naughty entities try to push malware or something through that URL. Is that enough motivation for a SHOULD for “rcdi”, at least for the referenced content case? We want that use case to work whether there are JWT Constraints present or not.
>> 
>> My personal preference would be to make it a MAY, and add non-normative guidance about when it would be a good idea to use it. I wouldn’t really object to making the JWT Constraint MAY if rcdi is present, and SHOULD in the specific use case you describe, but I wonder if we would not have problems thinking up an exhaustive list of all SHOULD cases in advance.
>> 
>> Thanks!
>> 
>> Ben.
>> 
>>> 
>>> Jon Peterson
>>> Neustar, Inc.
>>> 
>>> From: stir <[e-mail] <mailto:[e-mail]>> on behalf of Ben Campbell <[e-mail] <mailto:[e-mail]>>
>>> Date: Monday, September 9, 2019 at 3:07 PM
>>> To: Chris Wendt <[e-mail] <mailto:[e-mail]>>
>>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>> Subject: Re: [stir] Questions on the draft-ietf-stir-passport-rcd-04 integrity mechanism
>>> 
>>> Hi Chris,
>>> 
>>> 
>>> Please see inline.
>>> 
>>> Also, I forgot one comment unrelated to the integrity mechanism: in section 5.1, the wikimedia folks would probably appreciate it we do not include a link to content hosted there in an example in an RFC :-)
>>> 
>>> Thanks!
>>> 
>>> Ben.
>>> 
>>> 
>>>> On Sep 9, 2019, at 2:02 PM, Chris Wendt <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Hi Ben,
>>>> 
>>>> For 1, simple answer is yes the intention was to make the content tied to the cert.  My experience is that calling name and other info is not changed often, however, assuming your premise, why would that be a problem?  If you want to be changing your RCD info once a year, once a month, or once a day then why is it a problem to push everything through the integrity mechanism and generate a new cert each time?  I think this is pretty logical.  If you don’t do that, what is the alternative to keep the properties of integrity of the information protected by a signature?
>>> 
>>> I agree that tying the content to the cert makes sense for some use cases where there is a content policy “authority” either as part of the CA, or that easily fits in the workflow for issuing the cert (perhaps via some ACME-ish token) But I think there will also be use cases where it does not. In particular, cases where either there is no such authority, or the signer of the RCD PASSporT _is_ the authority.
>>> 
>>> For example, the policy authority could be a third-party signer as described in section 7. Why would such an authority need to tie content to the signing certificate? It would just make life more complicated for them. (I started to ask why a 3rd party signer would need the integrity mechanism at all, but perhaps they need to protect referenced content.).
>>> 
>>> I don’t object to having the _ability_ to tie content to the cert. But I think making that a MUST when using the integrity mechanism is too strong. I’d argue for a MAY, along with motivating text on why/when you might want to use it.
>>> 
>>> For similar reasons, I lean towards thinking the SHOULD for using the rcdi claim in the first place might be a bit strong. For example, it would serve little purpose in the third-party example above if the policy authority simply did not allow referenced content.
>>> 
>>> 
>>>> 
>>>> For 2, yes the intent was to iterate at each level of the URLs.  I suspect the number of nested URLs for most of the “common” cases, like name, logo and address, would be limited, but would need a framework that supports multiple levels of nesting or limit the number of levels or something if we are concerned.  I don’t think there is a lot of reason to be concerned but maybe i’m missing a case that would actually use a ton of nesting in any practical way.
>>> 
>>> If that is the intent, it needs to be clarified. I read 4.1.1 as iterating across all the URLs in the RCD input. I assume from your response that step 7 was intended to apply to retrieved content, but I initially assumed you mean to iterate over additionally identified URLs in the RCD claim itself.
>>> 
>>> Given the intent to recurse over multiple layers of indirect content, I think some operational guidance is even more important. My concerns were not so much around legitimate use cases for long URI chains so much as for more nefarious use cases (e.g. trying to sneak in uncontrolled web content, DOS attacks, etc.)  (Basically the concerns that Eric stated separately.)
>>> 
>>> 
>>>> 
>>>> -Chris
>>>> 
>>>> 
>>>>> On Sep 7, 2019, at 12:50 PM, Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> Minor correction below:
>>>>> 
>>>>> 
>>>>>> On Sep 6, 2019, at 4:31 PM, Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> Signed PGP part
>>>>>> Hi,
>>>>>> 
>>>>>> I have a couple of high level questions about the new integrity mechanism in draft-ietf-stir-passport-04. Apologies if these have already been discussed.
>>>>>> 
>>>>>> 1) Do I understand correctly that the certificate used to sign a PASSporT with an rcdi claim MUST include a constraint for the _value_ of the digest? That is, if someone makes any change to any of the information they would normally include in an rcd claim, the signing party must get a new cert?
>>>>>> 
>>>>>> My concern is that, for good or bad, commercial callers really like to control the customer experience. Many like to change things up all the time. I can imagine things like special date-specific logos (e.g. Google doodles), “sale” badges on logos, distinctive branding for different “campaigns”, etc.  I realize things like ACME make the process of getting a new cert lighter weight than it used to be, but is it reasonable to require a new cert for any change?
>>>>>> 
>>>>>> This might be worse for third-party signers who may sign on behalf of many callers, each of which keeps changing things.
>>>>>> 
>>>>>> 2) If I understand correctly, if anything in the rcd claim includes a URL, the rcdi claim incorporates the associated content. What about URLs?
>>>>> 
>>>>> Uhm, I meant to say additional URLs
>>>>> 
>>>>> 
>>>>>> For example, lets say a jcl key links to a jCard, and that jCard has a LOGO element with a URI? Is the alleged logo content at that URI protected?
>>>>>> 
>>>>>> I assume the answer is that the answer is no; otherwise it could be URLs all the way down and we have to stop somewhere. This is probably a matter of signer or issuer) policy. If so, it might be worth having some operational guidance that they need to think about such things.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> stir mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir