[Last-Call] Re: Secdir last call review of draft-ietf-sipcore-callinfo-rcd-13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yes, that works well. Thank you, Chris. I will update my review when the new draft version is published.

-- Christian Huitema

On 2/24/2025 5:27 AM, Chris Wendt wrote:
Ok, I did have a clause in the beginning to cover the direct inclusion but agree i sort of conflated the two issues. Hopefully the following modified edits make it clearer on both points:

The insertion of media directly or via Base64 encoding or using a remote URI that query network resources should be considered as a potential threat vector to the user or user agent that could potentially allow the parsing of documents crafted to trigger a bug or install a virus.  Remote access to URI content should additionally be considered as potentially exposing information about that user or user agent. Some sensitive users may desire the ability to control or disable these mechanisms entirely and methods to restrict or disable these potential concerns should be considered to mitigate these concerns.


On Feb 20, 2025, at 2:58 PM, Christian Huitema <huitema@xxxxxxxxxxx> wrote:

Almost there! But isn't it possible to encode "digital images and sounds directly via Base64 encoding"? The threat of "documents is crafted to trigger a bug and install a virus" can happen whether the document is downloaded or attached to the invite. I understand that image formats are restricted to SVG, BMP, JPG and PNG, which narrows the attack surface somewhat, but we have seen attacks through JPEG documents before -- and SVG appears like a rich target. Same goes for MP3 and MP4. The real paranoid will not just block downloading. They will want to block parsing of such fields.

-- Christian Huitema

I propose adding the following paragraphs to the security considerations section:

~~~~~~~
The SIP framework, defined in {{RFC3261}} and the various extensions to SIP, which stir {{RFC8224}} and rich call data {{I-D.ietf-stir-passport-rcd}} are included, since its existence has provided mechanisms to assert information about the person or entity behind the call. This can be a feature that can be a benefit to the SIP network that allows users to help identify the calling party behind an abstract telephone number.  It can also enable the ability for actors to impersonate a calling party they are not authorized to represent. The core security consideration that either explicitly or implicitly have been acknowledged with any of the SIP and stir specifications is that there is a management and policy layer that validates the participants in the ecosystem and their use of a SIP network with telephone number identifiers and identity related information.  The use of this specification should weigh this responsibility and make the appropriate considerations to validate the proper participation and use of these tools follow these larger security, impersonation prevention, and privacy considerations.

The use of this specification with the insertion of meta data related to a caller or the purpose of the call should recognize the risk that this information can be viewed by those network elements and participants in the delivery of the SIP call.
The insertion of media directly or that requires the use of remote URI that query network resources also should be considered as potentially exposing information about or is a potential threat vector to the user or user agent that some sensitive users may the ability to control or disable.  Methods to restrict or disable these potential concerns should be considered.

Largely, any information that is included in rich call data should be considered public and this specification does not define any mechanism to protect this information beyond the security and privacy associated with the SIP signalling itself.  This is a property that is consistent with SIP more generally and this specification follows a similar pattern for its use.

This specification contains the ability to include media resources and URI and URL resource references to media resources that could pose a threat when referencing or decoding the content of these media resources similar to threats that web browsers and other media decoding applications must be concerned about. A network specific set of policies or best practices for the use and hosting of media content that is agreed to contain validated media resources that have been evaluated to not pose a security threat to the participants or the devices supported in the ecosystem should be considered.
~~~~~~~

--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux