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

Will discuss this with my co-chair today.

I think the underlying fear is that there will be a call to abandon the
lower layer security because the upper layer one is "good enough" - the
argument that "we will still have the underlying p2p encryption" seems to
be falling on deaf ears.

(That said, I do NOT like the proposed key exchange mechanisms for
user-layer encryption - different topic.)

On Thu, Nov 29, 2018 at 7:33 AM Justin Uberti <> wrote:

> 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 <> 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]
>> [1]
>> [2]
>> <>
>> [3]
>> [4]

Received on Thursday, 29 November 2018 07:02:21 UTC