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

On Wed, Nov 28, 2018 at 10:31 PM Justin Uberti <juberti=
40google.com@dmarc.ietf.org> 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.
>

The consensus process for this technology was intended to include the IETF
community, which is the reason for this text in the charter. However,
that's not what's happening here.


Also, while I agree that WebRTC should coordinate with RTCWEB, RTCWEB is
> now closed.
>

RTCWEB is not in fact closed, though, as you say, that's the intention.
Presumably if necessary it could be kept open instead.

-Ekr

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