Statement from the IETF ART and SEC Area Directors regarding the "Trusted application, untrusted intermediary" use case

[Note: This message is addressed to Mark Nottingham in his role of the 
formal IETF-W3C liaison. The W3C WebRTC working group is copied 
specifically because of the ongoing "call for adoption" on that list to 
which this statement pertains. The IESG and W3C TAG are copied for their 
awareness. Martin Thompson is copied in his role of W3C liaison manager 
for the IAB. A formal liaison statement with the same contents will 
follow; this email is being sent in advance of the formal liaison 
statement to reach relevant parties prior to the conclusion of the "call 
for adoption".]

Esteemed colleagues:


The chairs of the W3C WebRTC working group have recently called for 
adoption of a use case [0] which specifies a media encryption scheme in 
which the "the application" (that is, the downloaded JavaScript) is 
considered a trusted party for the purpose of handling media keying 
information. This use case explicitly lists obtaining end-to-end keying 
information as a requirement of the solution [1].


During the Berlin IETF meeting in 2013, the RTCWEB working group had 
significant, multi-hour-long discussions around the security 
implications of giving browser-hosted JavaScript applications access to 
media keying information [2].  Substantial swaths of the IETF security 
community cautioned about the dangers of doing so. The conversation at 
the time was couched in terms of "SDES versus DTLS-SRTP," but the 
fundamental principle was whether the application could access the media 
keying information.


We fear that the ongoing call for adoption has the overall effect of 
subverting the WebRTC security framework [3][4] developed by the IETF, 
and of overriding the long-settled consensus achieved on this topic 
(captured in the second cited document as “...the system MUST NOT 
provide any APIs to extract either long-term keying material or to 
directly access any stored traffic keys”).


This proposed adoption also turns the security model of work underway in 
the IETF PERC working group on its head: if adopted, the technical 
solutions to satisfy the newly-proposed use cases would make it 
impossible to implement PERC in a web browser context, as they would 
necessarily deliver media keying information directly to the one party 
that PERC is predicated on not trusting.


We object to the proposed course of action on two fundamental grounds. 
First, this action unilaterally reverses the established consensus on a 
fundamental security feature of WebRTC. Second, this action subverts 
ongoing work in the PERC working group without consultation of the 
interested parties.


We remind the W3C that the charter of the W3C WebRTC working group 
indicates that "The security and privacy goals and requirements will be 
developed in coordination with the IETF RTCWeb Working Group," while the 
charter of the IETF RTCWEB working group includes in its scope 
"Defin[ing] a security model that describes the security and privacy 
goals and specifies the security protocol mechanisms necessary to 
achieve those goals." These charters, which were developed in concert 
with each other, make it clear that any changes to the fundamental 
security guarantees of the media model used by WebRTC need to be 
performed in coordination with the appropriate working groups in the 
IETF. With the impending conclusion of RTCWEB, these venues would 
include MMUSIC, PERC, and SAAG.


More immediately, we request that the chairs of the WebRTC working group 
retract the ongoing call to adopt the aforementioned use cases as 
in-scope for the working group until the security properties can be 
discussed in appropriate IETF venues.


Sincerely,


Adam Roach

Ben Campbell

Alexey Melinikov

  Area Directors, IETF Applications and Real-time Area


Eric Rescorla

Benjamin Kaduk

  Area Directors, IETF Security Area


____

[0] 
https://www.w3.org/mid/5f463a3b-2994-2028-7cdd-3439208df979@alvestrand.no

[1] https://w3c.github.io/webrtc-nv-use-cases/#securecommunications

[2] 
https://datatracker.ietf.org/doc/minutes-87-rtcweb/<https://tools.ietf.org/wg/rtcweb/minutes?item=minutes-87-rtcweb.html>

[3] https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.3.1

[4] 
https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-17#section-6.5