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 <juberti@google.com> 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 <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
>>
>>
>>