Re: [appsdir] [rtcweb] Fwd: Request for Apps Directorate review of rtcweb-security drafts
Eric Rescorla <ekr@rtfm.com> Tue, 04 August 2015 16:42 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: appsdir@ietfa.amsl.com
Delivered-To: appsdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2171A87E6 for <appsdir@ietfa.amsl.com>; Tue, 4 Aug 2015 09:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoH3AW32kwNE for <appsdir@ietfa.amsl.com>; Tue, 4 Aug 2015 09:42:36 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213EE1A87AD for <appsdir@ietf.org>; Tue, 4 Aug 2015 09:42:36 -0700 (PDT)
Received: by wijp15 with SMTP id p15so13963733wij.0 for <appsdir@ietf.org>; Tue, 04 Aug 2015 09:42:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LsgSaRxTB7DEkpAGR0kWhn+H7w0VXGNObs5K2Hu4RkU=; b=hecfSrqDBvPser26XQkJ5uPKo76BIav45hsqJcdJbxXGZbbBNp/zaTuZol58MNxxUI /pud9eqv9nu4iunp3qpoKrJ8zG2aTYzeQ67KT5l8LMA74VGBDLgr+GlR8dstjgsqINLH nEiqGYncQgxVbZBl23oNplGXyd63bjTiNqOYKL/C5KjtDw8VGF1Clx695D71fprPnFYO +zRgtM+w3YTTlT/MFGuPBMj7UPCKFxCYQi6WxeQ3rEQRoKi48Xk4xrZxNHiqTrT7FFCs vfkBIus/74s385jt6ErjAq0keR/5g0CNUuWSIrNFBj/JgElMVAV8bEtu9eLk0lFNZkr2 9rlw==
X-Gm-Message-State: ALoCoQmom9nyVPz/PI+nTHavDULi6ZMYsZPXxqIQl0pym3LJVwxJMx6deeln3NXlB88zykW6nCNX
X-Received: by 10.180.91.79 with SMTP id cc15mr10019129wib.53.1438706554827; Tue, 04 Aug 2015 09:42:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.86 with HTTP; Tue, 4 Aug 2015 09:41:55 -0700 (PDT)
In-Reply-To: <BL2PR03MB2900414B69109280FD682B5AD770@BL2PR03MB290.namprd03.prod.outlook.com>
References: <CA+9kkMCp-CRKo0=Vh4=5UcAQ4KjzXuD4g79cU2ciZ0Jcq5kznQ@mail.gmail.com> <558C4C02.3000404@cisco.com> <BL2PR03MB2909F4C8048C36D877D4C30ADAE0@BL2PR03MB290.namprd03.prod.outlook.com> <558C5CA3.7020108@cisco.com> <BL2PR03MB2901887F19BE749F15F86B6ADAE0@BL2PR03MB290.namprd03.prod.outlook.com> <BL2PR03MB29098E37662A2C4DFFDD402AD9B0@BL2PR03MB290.namprd03.prod.outlook.com> <CA+9kkMBD4NRsM6Kq3zmF1L2GDJzjBKBbgvJZfcf2i5jFm2PjgQ@mail.gmail.com> <BL2PR03MB2900414B69109280FD682B5AD770@BL2PR03MB290.namprd03.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 04 Aug 2015 09:41:55 -0700
Message-ID: <CABcZeBO0r-1PiMmHJL=aXLnWVSRj6yvMHCeEq9gErTCF72etvQ@mail.gmail.com>
To: "Orit Levin (LCA)" <oritl@microsoft.com>
Content-Type: multipart/alternative; boundary="f46d043be246230c45051c7ef99a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/appsdir/74h0mmx18r0FFjTD_Pug0DVpy3k>
Cc: Ted Hardie <ted.ietf@gmail.com>, "appsdir@ietf.org" <appsdir@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Eliot Lear <lear@cisco.com>
Subject: Re: [appsdir] [rtcweb] Fwd: Request for Apps Directorate review of rtcweb-security drafts
X-BeenThere: appsdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Apps Area Review List <appsdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/appsdir>, <mailto:appsdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/appsdir/>
List-Post: <mailto:appsdir@ietf.org>
List-Help: <mailto:appsdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/appsdir>, <mailto:appsdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 16:42:40 -0000
I'll be handling this along with the rest of the review comments I have received, at the next draft update (probably before the next RTCWEB/WebRTC interim) but I don't have a specific ETA. -Ekr On Mon, Aug 3, 2015 at 4:43 PM, Orit Levin (LCA) <oritl@microsoft.com> wrote: > Hi guys, > > Three busy weeks and an IETF meeting have past… When should we expect to > see the feedback to the review? > > Thanks and cheers, > > Orit. > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* Tuesday, July 14, 2015 11:18 AM > *To:* Orit Levin (LCA) <oritl@microsoft.com>; rtcweb@ietf.org > *Cc:* Eliot Lear <lear@cisco.com>; appsdir@ietf.org > > *Subject:* Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb-security drafts > > > > (adding the WG) > > Hi Orit, > > Thanks for the review. > > regards, > > Ted Hardie > > > > On Tue, Jul 14, 2015 at 11:07 AM, Orit Levin (LCA) <oritl@microsoft.com> > wrote: > > Disclaimer: I am familiar with RTC and WebRTC, but I haven't followed the > RTCWeb work in the last few years. I read the two drafts for the first time. > Therefore, my apologies for potentially raising points that have been > discussed in the past. > > >From the APP (or ART) review perspective, my main comment is on the topic > of "Web-Based Peer Authentication". While it is not clear from the text, > which parts are already standardized concepts (e.g., by W3C) and which are > introduced here for the first time, the described approach seems to be (1) > useful to web applications beyond WebRTC, (2) under development and thus > probably not stable, and (3) too detailed for "an architecture" document. > As such, the concept of " Web-Based Peer Authentication" probably needs to > be introduced and standardized under the Security Area and then adopted by > WebRTC and other apps. > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > This document contains an excellent collection of security threats to > WebRTC and discusses many different ideas for their potential mitigation. > That being said, it is not an easy read. Specifically, from high level to > more specific: > 1. The intended status of the document is Standards Track, while a typical > status of a "security threat model" RFC is Informational. This discrepancy > probably lies in the current scope of the document. See the next comment > below. > 2. The scope of the document is not clear. In addition to describing the > security threats (and the requirements or user expectations related to > their prevention), in many places the document lists potential solutions > with their perceived limitations and/or applicability. Examples are > sections: 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.2.1, 4.3.2.2, 4.3.2.3. To improve > the document's readability and reduce overlaps, the solutions should be > introduced and explained in the companion "architecture" document. > Solutions' applicability to different use cases needs to be provided in a > non-bias way. > 3. Apart from the brief Introduction with a few examples, there is no > description of the WebRTC threat model putting all main types of threat in > one place. For example, the "Communications Security" aspect is introduced > for the first time in Section 4.3 only. The start of Section "4. Security > for WebRTC Applications" could be a logical place for introducing the > WebRTC threat model. > 4. The "simple WebRTC system" presented in the Introduction in Figure 1 is > inadequate to illustrate many of the scenarios and points discussed in the > document. For example, see the discussion around media origin vs. web > origin in Section 4.1.3. > 5. Section "3. The Browser Threat Model" is an overview of the existing > web security architecture and some current practices. As such, references > to relevant standards (e.g., W3C) and common practices need to be added > within the text to help the reader to understand the status of the > information and to follow the sources. > 6. The last paragraph in Section 4.1 conveys a key point in the whole > WebRTC threat model. As such, it needs to be moved to the start of the > discussion where the threat model is introduced (see comments above). > 7. Stylistically, the document would benefit from removing non-standards > vocabulary, i.e., "to bug", "to bug me", "no real way", "it is important to > require", "extremely aggressive intermediates", and "for obvious reasons", > etc. > 8. Suggestions for renaming some of the sections to improve readability: > "3. The Browser Threat Model" -> " 3. Overview of the Existing Web Threat > Model" > "4.1. Access to Local Devices" -> "4.1. Consent to Access Local Resources" > "4.1.2. Calling Scenarios and User Expectations" -> "4.1.2. Scope of > Consent in Various Calling Scenarios" > "4.1.2.1. Dedicated Calling Services" -> "4.1.2.1. Long-term Consent" > "4.1.2.2. Calling the site You're On" -> "4.1.2.2. Short-term Consent" > "4.1.3. Origin-Based Security" -> "4.1.3. Web Attackers and Origin-based > Security" > "4.1.4. Security Properties of the Calling Page" -> "4.1.4. Network > Attackers and Security Properties of the Calling Page" > "4.2. Communications Consent Verification" -> "4.2. Consent to Receive > Traffic" > "4.3.3. Malicious Peers" -> "4.3.3. Out of Scope" > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > This document is in a much better state in terms of its organization and > readability. It introduces the security architecture using an example and > then lists possible approaches to implement it. Some approaches are > described on a high level by referencing other documents, while others are > introduced for the first time in this document together with their > implementation details. By just reading the document, it is difficult to > judge whether these details are sufficient or stable enough for > implementation. In general, I doubt that this is the best approach for an > "architecture" document, which is supposed to serve as a long term stable > reference. > More specific comments: > 1. Different terminology is used throughout the document to address same > or close concepts. It would help a lot to explain the concepts upfront and > then to use the terminology consistently. Currently it includes "client", > "endpoint", "peer", "user"; "implementation", "browser", "chrome", "API", > "JS"; "application", "server", etc. > 2. The discussion is phrased in terms of "authentication" and "trust". In > think that "authorization" instead of "trust" would be a better technical > term, for example, in Section 3.1. > 3. In section 4. Overview, sentence "the tension between security (or > performance) and privacy" is not clear, especially because it doesn't seem > to correspond to Section 6.2. (BTW "tradeoff" would be a better word than > "tension".) > 4. Section "4.1. Initial Signaling", the text is inconsistent in terms of > whether Alice and Bob share or use different identity providers. > 5. Section "4.1. Initial Signaling", reference to PeerConnection needs to > be added. > 6. Section "4.2. Media Consent Verification" and Section "5.3 > Communications Consent": the name/terminology of this functionality needs > to be harmonized. The ICE-based solution with its pros, cons as well as the > alternatives (applicable to different use cases) need to be moved from the > companion threat model document to this "architecture" one. > 7. A suggestion: rename "5. Detailed Technical Description" to "5. > Security Architecture Components". > 8. In Section 5.2., "Implementations which support some form of direct > user authentication..." -> "Implementations that support some form of > direct user authentication..." > 9. Section "5.6. Web-Based Peer Authentication" and section "5.6.2. > Overview of operation": It is not clear, which parts are standardized > concepts (e.g., by W3C) and which are introduced here for the first time. > If exist, references to existing standards need to be added. The described > architecture and the technical details seem to be (1) under development and > thus probably not stable, (2) too detailed for "an architecture" document > and (3) useful beyond WebRTC. As such, the concept of the " Web-Based Peer > Authentication" probably needs be introduced under the Security Area and > then adopted by WebRTC. > 10. The web-based peer authentication using IdP is not the only mechanism > applicable to WebRTC. Moreover, the web-based peer authentication is not > the only approach applicable to WebRTC. Alternatives are listed in the > companion document and need to be moved here to the "architecture" document > with their pros and cons presented in an unbiased way. > 11. Stylistically, the document would benefit from removing non-standards > vocabulary, i.e., "some Web server", "can't really trust", "that much", > "fairly conventional", "simply have", "a little anticlimactic", etc. ;-) > > Thanks, > Orit. > > > > -----Original Message----- > > From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Orit Levin > > (LCA) > > Sent: Thursday, June 25, 2015 1:17 PM > > To: Eliot Lear; appsdir@ietf.org > > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > security drafts > > > > Perfect! I have a very long flight on the 7th... So right after then or > earlier. > > Orit. > > > > > -----Original Message----- > > > From: Eliot Lear [mailto:lear@cisco.com] > > > Sent: Thursday, June 25, 2015 12:55 PM > > > To: Orit Levin (LCA); appsdir@ietf.org > > > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > > security drafts > > > > > > Thank you Orit! Can you try to have them done in about two weeks? > > > > > > Eliot > > > > > > On 6/25/15 9:52 PM, Orit Levin (LCA) wrote: > > > > I will be happy to take a look at them! > > > > Orit. > > > > > > > >> -----Original Message----- > > > >> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Eliot > > Lear > > > >> Sent: Thursday, June 25, 2015 11:44 AM > > > >> To: appsdir@ietf.org > > > >> Subject: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > > >> security drafts > > > >> > > > >> Dear Appsdir folk, > > > >> > > > >> Could I have a volunteer to review the following two drafts? > > > >> > > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > > > >> > > > >> and > > > >> > > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > > > >> > > > >> Ted is exempt, having made the request ;-) > > > >> > > > >> Eliot > > > > > > > _______________________________________________ > > appsdir mailing list > > appsdir@ietf.org > > https://www.ietf.org/mailman/listinfo/appsdir > > _______________________________________________ > appsdir mailing list > appsdir@ietf.org > https://www.ietf.org/mailman/listinfo/appsdir > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > >
- [appsdir] Fwd: Request for Apps Directorate revie… Eliot Lear
- Re: [appsdir] Fwd: Request for Apps Directorate r… Orit Levin (LCA)
- Re: [appsdir] Fwd: Request for Apps Directorate r… Eliot Lear
- Re: [appsdir] Fwd: Request for Apps Directorate r… Orit Levin (LCA)
- Re: [appsdir] Fwd: Request for Apps Directorate r… Orit Levin (LCA)
- Re: [appsdir] Fwd: Request for Apps Directorate r… Ted Hardie
- Re: [appsdir] Fwd: Request for Apps Directorate r… Orit Levin (LCA)
- Re: [appsdir] [rtcweb] Fwd: Request for Apps Dire… Eric Rescorla
- Re: [appsdir] [rtcweb] Fwd: Request for Apps Dire… Orit Levin (LCA)
- Re: [appsdir] [rtcweb] Fwd: Request for Apps Dire… Ted Hardie
- Re: [appsdir] [rtcweb] Fwd: Request for Apps Dire… Orit Levin (LCA)