Re: [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts
Ted Hardie <ted.ietf@gmail.com> Tue, 14 July 2015 18:18 UTC
Return-Path: <ted.ietf@gmail.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 B95761AD49B; Tue, 14 Jul 2015 11:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 TbMReumkcvci; Tue, 14 Jul 2015 11:18:27 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 EE6801AD2B2; Tue, 14 Jul 2015 11:18:25 -0700 (PDT)
Received: by widjy10 with SMTP id jy10so107110686wid.1; Tue, 14 Jul 2015 11:18:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gNZws9RhcC4HkIpb4k9L2THRb7QVmtI9Al6uNBYjK3Q=; b=Ol4iNsHuNUO+B3CNruETUqYuEJTgGs2GFoa0OH+g7Pom8TU9GTLNIifFNK+1dSZdIc kV5w82IkEAR/edReBjES34Dezo2PhtJSsL2Cs4HFDy4Cn1j66gZKoS0FubbPTQb58B25 zt405fxu6ZZdzYm4RH1G5Uh16L4njEiyAlXRLRjE8jgL8NP0Uwy6UlKOUdqAAli1RUSg nNiECLh8eS3XUT4KoQs3Lgn99dMBtluX/97on6yCA8HaCW6MMKpRNjTOvvR9Xgmz3SsD kHaDAGSs/GEcvaEWhA/09dvns4LNpTWUDrd9oD+k7CaFzgmbAdxuejR5OL80tdE0gkQp ugMg==
MIME-Version: 1.0
X-Received: by 10.180.80.138 with SMTP id r10mr7803328wix.18.1436897904660; Tue, 14 Jul 2015 11:18:24 -0700 (PDT)
Received: by 10.194.17.68 with HTTP; Tue, 14 Jul 2015 11:18:24 -0700 (PDT)
In-Reply-To: <BL2PR03MB29098E37662A2C4DFFDD402AD9B0@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>
Date: Tue, 14 Jul 2015 11:18:24 -0700
Message-ID: <CA+9kkMBD4NRsM6Kq3zmF1L2GDJzjBKBbgvJZfcf2i5jFm2PjgQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: "Orit Levin (LCA)" <oritl@microsoft.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="f46d0444038a2f94a8051ad9dd9c"
Archived-At: <http://mailarchive.ietf.org/arch/msg/appsdir/QEFNMJWZ_xBHuEMIid94lMA7mEg>
Cc: "appsdir@ietf.org" <appsdir@ietf.org>, Eliot Lear <lear@cisco.com>
Subject: Re: [appsdir] 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, 14 Jul 2015 18:18:31 -0000
(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 >
- [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)