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

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