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: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Thu, 29 Nov 2018 09:52:11 +0100
To: public-webrtc@w3.org
Message-ID: <d425032d-4591-86e4-48d9-93db9078c5c2@gmail.com>
Also, taking the keying issue aside, it is taken for granted that the 
lower layer security exists and that we will use PERC for it, when 
perc-double has huge impact on webrtc as it requires to modify all 
stacks so the RTX+FEC processing is done AFTER the encryption (and not 
before as in 1.0). As we will not be likely want to break compatibility 
with 1.0 and non-perc endpoints we will still have to support current 
processing order additionally.

On 29/11/2018 8:01, Harald Alvestrand wrote:
> 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 
> <mailto: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
>     <mailto: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 08:48:55 UTC

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