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