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