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

[Ben Campbell <[e-mail]>]

I meant to add “There’s always the potential for adversarial content in that body part” to the list.

Thanks!

Ben.

> On Mar 6, 2023, at 1:09 PM, Ben Campbell <[e-mail]> wrote:
> 
> (No hats)
> 
> I think that CID security requirements are similar but not identical to HTTPS: CID URLs would reference body parts imbedded in the SIP INVITE, so there’s effectively no server. But we are still talking about content external to the PASSporT not directly covered by the PASSporT signature, so integrity protection still matters.
> 
> Given that this is not something the WG has really thought about, I propose we limit this to HTTPS for the time being. If anyone really needs CID, they can always bring an update or bis draft with the appropriate security considerations.
> 
> Thanks!
> 
> Ben.
> 
>> On Mar 6, 2023, at 11:27 AM, [e-mail] wrote:
>> 
>> I don’t know how much CID is in use, so I think you have to require HTTPS at least.
>>  
>> I don’t have an opinion on whether you should specify “MUST be HTTPS or CID”.
>>  
>> I remember that Alec Fenichel added some requirements to the ATIS-1000074 spec with regard to caching, port numbers for HTTPS and defense against SSRF.  I don’t know if those would have been good to have also included the IETF RFC 8224 spec, but just want to mention that if there are similar performance and/or security considerations for CID, and you decide to include CID in this spec, you might want to see if there are any similar recommendations for CID as were available for HTTPS.
>>  
>> Pierce
>>  
>>  
>> From: stir <[e-mail] <mailto:[e-mail]>> On Behalf Of Chris Wendt
>> Sent: Sunday, March 5, 2023 9:03 AM
>> To: Ben Campbell <[e-mail] <mailto:[e-mail]>>
>> Cc: Roman Danyliw <[e-mail] <mailto:[e-mail]>>; The IESG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; STIR Chairs <[e-mail] <mailto:[e-mail]>>; IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>; Russ Housley <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: [stir] Roman Danyliw's Discuss on draft-ietf-stir-passport-rcd-23: (with DISCUSS and COMMENT)
>>  
>> Hi Ben,
>>  
>> Yes, thanks for catching that, perhaps HTTPS or CID is best path.  Curious for other opinions.
>>  
>> -Chris
>> 
>> 
>>> On Mar 2, 2023, at 5:01 PM, Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote:
>>>  
>>> (No hats)
>>>  
>>> I have a context related comment on one item:
>>>  
>>> Thanks!
>>>  
>>> Ben.
>>> 
>>> 
>>>> On Mar 1, 2023, at 12:02 PM, Chris Wendt <[e-mail] <mailto:[e-mail]>> wrote:
>>>  
>>> […]
>>> 
>>> 
>>>>  
>>>>> 
>>>>> ** 5.*. Inconsistent requirements for URIs
>>>>> 
>>>>> -- icn: appears to be any URI per Section 5.1.3.  This would make gopher://,
>>>>> ftp://, https:// all equally valid.  These have different security
>>>>> characteristics.
>>>>> 
>>>>> -- jcd: per Section 5.1.4 “is intended to directly match the Call-Info header
>>>>> field value defined in [I-D.ietf-sipcore-callinfo-rcd].” Section 4 of that
>>>>> document says it “MUST define the use HTTPS or a transport that can validate
>>>>> the integrity of the source of the resource as well as the transport channel
>>>>> through which the resource is retrieved”.
>>>>> 
>>>>> -- jcl: is an HTTPS URL (per Section 5.1.5)
>>>>> 
>>>>> Why are these different?  Support different levels of transport security?
>>>> 
>>>> You are correct, i fixed “icn” to specifically be an HTTPS URL vs generic URI.  jcd is not a URI, it’s a directly included JSON jcard object in the “rcd" claim.
>>>> 
>>>  
>>> IIRC, a previous version did specify HTTPS URLs for “icn”, but we discussed the possibility that an icon could be imbedded in a body part of the SIP request and be referenced with a “cid” URL. I suppose that if that is true for “icn”, it is probably also true for “jcl”.
>>>  
>>> That being said, I am not aware of anyone actually doing that (yet) will not object if we think it is better to limit it to HTTPS. (Or as a compromise,  say it MUST be either HTTPS or CID?)
>>>  
>>> 
>>> 
>>>> […]
>