Re: [appsdir] [rtcweb] Fwd: Request for Apps Directorate review of rtcweb-security drafts

Ted Hardie <ted.ietf@gmail.com> Tue, 04 August 2015 23:16 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 AABED1A00AE; Tue, 4 Aug 2015 16:16:25 -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 Pa_K9m2M9PEM; Tue, 4 Aug 2015 16:16:21 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 9E58F1A1A5B; Tue, 4 Aug 2015 16:16:20 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so43134590wib.1; Tue, 04 Aug 2015 16:16:19 -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=qkiW6YkVzTf/qOwmCY99f9iAEp2pQajj4WlyjhK2ZAo=; b=g4sZFyF42QsXa3TAKW9hY2avq9HGv6chZUpmP0yUd6Cm/VQ09T/XQ0KEwfm5wzpWF9 NSZU1ot5FkzxnDZ773A+tUOrtcf8LrAj7byHo9659BZCwrxuObxZ4V70O1e3tEGwdxnX 3cHKUWg6thabWRTD5+E+h3/Z3s5ynJCPR5U2g63QLShFmcG9mCN+xzKRCTiLK6fsS+l5 gep89SMzr374kdeu0cxAKPown4vzLlAfei1naYMMXs4fl6+y2mwqsOfcYeUc72a5uQgw LPu3qHtQ2j2IoVpl+zgIMIbX8bbfLNAKYc5HsFfZJLXI+psIFv/jzmO3Ggp2YpnuIalV CnPw==
MIME-Version: 1.0
X-Received: by 10.194.108.232 with SMTP id hn8mr13122174wjb.154.1438730179381; Tue, 04 Aug 2015 16:16:19 -0700 (PDT)
Received: by 10.194.17.68 with HTTP; Tue, 4 Aug 2015 16:16:19 -0700 (PDT)
In-Reply-To: <BL2PR03MB2909277FDAF9F0F339D2476AD760@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> <CABcZeBO0r-1PiMmHJL=aXLnWVSRj6yvMHCeEq9gErTCF72etvQ@mail.gmail.com> <BL2PR03MB2909277FDAF9F0F339D2476AD760@BL2PR03MB290.namprd03.prod.outlook.com>
Date: Tue, 4 Aug 2015 16:16:19 -0700
Message-ID: <CA+9kkMDtgPcsNvV_wWsypZsf3ivC_BHBpnnyVRDEmtBB6FnMcQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: "Orit Levin (LCA)" <oritl@microsoft.com>
Content-Type: multipart/alternative; boundary=047d7bf198a0450e18051c8479d3
Archived-At: <http://mailarchive.ietf.org/arch/msg/appsdir/dd2rwA7qjvG4jlsjOybLuQ5UPI8>
Cc: Eric Rescorla <ekr@rtfm.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 23:16:25 -0000

On Tue, Aug 4, 2015 at 3:30 PM, Orit Levin (LCA) <oritl@microsoft.com>;
wrote:

> Thanks, Ekr! Looking forward to reading the next version of the drafts.
>
> Whenever it works best for you, could you, please, reply to the original
> email showing inline how each comment got addressed? That would help a lot.
>
> Cheers,
>
> Orit.
>
>
>

​Hi Orit,

I think our aim is to describe how comments were addressed in the shepherd
write-up; I'll take the action item to make sure you get a copy.

Ted​



>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* Tuesday, August 04, 2015 9:42 AM
> *To:* Orit Levin (LCA) <oritl@microsoft.com>;
> *Cc:* Ted Hardie <ted.ietf@gmail.com>;; rtcweb@ietf.org; appsdir@ietf.org;
> Eliot Lear <lear@cisco.com>;
> *Subject:* Re: [rtcweb] [appsdir] Fwd: Request for Apps Directorate
> review of rtcweb-security drafts
>
>
>
> 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
>
>
>