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
