Thanks, Chris. These additional paragraphs would go a long way towards
addressing my concerns, but I think we still have an issue of agency.
You recommend "a network specific set of policies or best practices".
This is certainly a good way to protect the general public, but does not
address the "one size fits all" worry. The network policy should be
complement by options for sensitive users to control or disable some or
all of the mechanisms -- for example, don't "call home" and don't
attempt to parse complex media types.
-- Christian Huitema
On 2/17/2025 6:40 AM, Chris Wendt wrote:
Hi Christian,
Thanks for your review. I agree with your general concerns and this has been an ongoing discussion for both SIP more generally and recently with stir as a mechanism that is supporting larger security frameworks that impose an ecosystem specific set of policies for the participation in the SIP network, but also for the importance of vetting of entities behind a telephone number and the information and metadata that is asserted within frameworks like call-info and rich call data.
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. 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.
~~~~~~~
Hopefully those statements help address your concerns. If you aren’t aware, much of these security related policies and frameworks are being put in place and many of your concerns have been echoed my many technical and product leaders and policy makers associated with telephone networks around the world already. The telecommunications industry is absolutely taking this very seriously. Obviously there is a lot of potential liability associated with getting it wrong, so we are on a good path to carefully, slowly, purposefully add these important features that are common in many communications apps to the public telephone network. It’s very important work that no one is taking lightly.
I will submit a -14 that adds these changes along with addressing other review comments.
Thanks!
-Chris
On Feb 15, 2025, at 3:18 PM, Christian Huitema via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Christian Huitema
Review result: Has Issues
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
The summary of the review is Almost Ready.
I have a major concern about the whole idea of providing "Rich
Call Data" (RCD) in SIP calls. Making the call data richer is a tradeoff
between ease of use and increased attack surface, with possible
implications for privacy and safety of the called parties. Many
users may fell that the ease of use is worth the increased risks,
but we cannot assume that "one size fits all". Journalists or
political opponents, for example, should be reluctant to make
such tradeoffs. I will detail these risks in the reminder of
the review. I wish that risks and tradeoffs be explicitly
delineated in a revised security section.
This document defines a framework for the use of Call-Info
header field to carry RCD in SIP [RFC3261].
It expands the use of parameters such as "purpose", "icon",
adds a "jcard" token to the purpose token, and add new
parameters such as "call-reason", "verified" and "integrity".
The design "assumes that the called party UA
can trust the SIP network or the SIP provider to assign, deliver, and
protect the correct RCD information as an end-to-end security policy",
but also recommends 'that the calling party signs the caller
information through the use of RCD or the "rcd" PASSporT defined in
[I-D.ietf-stir-passport-rcd].'
In this review, I assume that the "STIR PASSporT" mechanism works as
intended, and that when it is use the receivers can safely assume that
the received information matches the values set by the calling party.
That assurance would be greater if it was mandatory to sign using
"STIR PASSporT" instead of merely optional. But "matching the callers
intent" is not the same as "matching the callee's privacy and
safety requirements".
My first concern is that the richer information may be used to
make spam more convincing, and maybe in harassment campaigns. The
callers can state a "call purpose" of their choice, and pick any
icon. Displaying the caller's picture when the phone rings seems
cool, but spammers will love displaying a picture of the wares
that they are pushing, and harassment campaigns can use purpose
and icons to great effects.
The second concern is the leakage of richer meta-data along the call path.
We all heard the classic quote about "killing people because of metadata",
adding purpose of call surely helps that. One of the examples
has the call reason set to "For your ears only", which is not the
kind of data J. Bond and Q might want to see stored in a variety
of network archives. Users and UI designers should be aware that
the call data is not encrypted end-to-end.
Then there is the call home effect: visualizing the elements in the vcard
requires downloading data from a URI designated by the caller. If the URI
points to a server controlled by the caller, contacting the server informs
this caller about the processing of the call. The caller will learn
the current IP address of the callee and thus its location -- and they will
learn that whether the callee accepts the call or not.
Finally, there is the risk of Pegasus-like attacks. Remember how Pegasus was
exploiting bugs in the handling of various media formats to install a virus
on a target phone? I think we have similar risks here. Callers could use creative
JSON syntax, or ask the receiver to parse a logo or icon in an obscure format.
Automatically loading media and structured data substantially increases the
attack surface of the calling system.
Different users may have different risk profiles. We see that is current
deployments, with phones treating calls differently if the caller is "unknown",
and at risk users adopting a very restricted communication profile. An
example of restriction would be to never display "rich call data" from
unknown callers. Another would be to never download information from
remote servers. Yet another would be to never process rich call data
if not signed using "STIR PASSporT". These are all different levels of
tradeoffs between ease of use and safety. I think that the security
section should point out the risk and suggest that UA designs allow
different users to pick different configurations.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
