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

[[e-mail]]

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]> On Behalf Of Chris Wendt
Sent: Sunday, March 5, 2023 9:03 AM
To: Ben Campbell <[e-mail]>
Cc: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>; [e-mail]; STIR Chairs <[e-mail]>; IETF STIR Mail List <[e-mail]>; Russ Housley <[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?)

 





[…]