W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2018

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

From: Justin Uberti <juberti@google.com>
Date: Wed, 28 Nov 2018 22:31:17 -0800
Message-ID: <CAOJ7v-36+bF7Qnzb3SXysKyhEzGO4sz1Q5Nn4JLj2YsEryHFhQ@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: mnot@yahoo-inc.com, www-tag@ietf.org, public-webrtc@w3.org, The IESG <iesg@ietf.org>, mt <mt@mozilla.com>

Understand the concerns here, but requesting the abandonment of a consensus
call feels really heavy-handed, and suggests a lack of faith in the
consensus process. From my perspective, the dialog on the WebRTC list was
constructive and included reasonable perspectives from both sides of the

Also, while I agree that WebRTC should coordinate with RTCWEB, RTCWEB is
now closed. Perhaps that decision was premature; it's not clear that MMUSIC
is a better venue to discuss web security than a W3C WG.


On Wed, Nov 28, 2018 at 2:20 PM Adam Roach <adam@nostrum.com> wrote:

> [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
Received on Thursday, 29 November 2018 06:31:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:45 UTC