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

State Posted
Submitted Date 2018-11-28
From Groups ART, SEC
From Contact Mark Nottingham
To Groups W3C, W3C-WEBRTC
To Contacts bernard.aboba@gmail.com
harald@alvestrand.no
Wendy Seltzer
Philippe Le Hégaret
CcAdam Roach
Ben Campbell
Benjamin Kaduk
Mark Nottingham
The IETF Chair
Alexey Melnikov
Eric Rescorla
public-webrtc@w3.org
mt@mozilla.com
www-tag@w3.org
Response Contact Adam Roach
Ben Campbell
Alexey Melnikov
Eric Rescorla
Benjamin Kaduk
Purpose For action
Deadline 2018-12-31 Action Needed
Attachments (None)
Body
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/
[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