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

Folks,

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
debate.

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.

Respectfully,
Justin



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
>
>
>