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

"Orit Levin (LCA)" <oritl@microsoft.com> Tue, 04 August 2015 22:30 UTC

Return-Path: <oritl@microsoft.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 739941A8988; Tue, 4 Aug 2015 15:30:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 5ditOEXUc-qL; Tue, 4 Aug 2015 15:30:30 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB8E1A8777; Tue, 4 Aug 2015 15:30:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hg7LHcUEkgT1dUTkKkYTNAQh94sFO7nPOB2TWG1cYR8=; b=b/JAM17Tvty1VzFXPC97U7yumjxjjV2w4jEuWMUXUnWMc0wi1RfsSrtO61nGqKc3mOgB8BXHrSlEQqX20T/4tVO9P+5Oi9i7VZWd3Giw6pMgn6SSjjga7Dlx/vxQ4XJps/1gnt+kf1wH9g6u4H92Oxjk6VBuqHKKvbCsIW2SIQ4=
Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BL2PR03MB291.namprd03.prod.outlook.com (10.141.68.25) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 22:30:07 +0000
Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 22:30:07 +0000
From: "Orit Levin (LCA)" <oritl@microsoft.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [rtcweb] [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts
Thread-Index: AQHQr4DcT2qcK6DgvkiqLOtwc4J9zZ29oujwgBRIQaCACXjGAIAfyB6QgAEd44CAAFuUQA==
Date: Tue, 4 Aug 2015 22:30:06 +0000
Message-ID: <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>
In-Reply-To: <CABcZeBO0r-1PiMmHJL=aXLnWVSRj6yvMHCeEq9gErTCF72etvQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=oritl@microsoft.com;
x-originating-ip: [2001:4898:80e8:2::3a7]
x-microsoft-exchange-diagnostics: 1; BL2PR03MB291; 5:FW24PrAnnU2omZTazryzbtDDXi4b5QgfO4JApAnBoV21YP/kmj7+8SFEuk7aYEZ1eejEJbPRH8KBAo0q87pathlAEd0pE6PP+dVf2qKalIIlk5ihw+KU7HGcD4qYslVxPwoL4squTTgAXheC0AYZfg==; 24:ua36Fd8uoGYwFTMUFzBrSD+3A06Ceav4G6dNr7R08rfYLL1KQgf/l8EGfLJzMzX+3fXIi/ccBT7n1SKxqjH6+Yrhvl0pQ1WDjavdPS3yQSk=; 20:+YGeNyKas5DcdMP3k4W9Qe4dcPnApzM+/Lk88z8J9RgDzdLB6is6//sRuJbEhsf6UClPf9BmFuD5lfWxoTyMoA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB291;
x-microsoft-antispam-prvs: <BL2PR03MB2917CFE8D82037889EF3749AD760@BL2PR03MB291.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB291; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB291;
x-forefront-prvs: 0658BAF71F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(479174004)(2473001)(164054003)(189002)(377454003)(13464003)(51914003)(24454002)(10090500001)(77156002)(74316001)(19580405001)(86362001)(19580395003)(106116001)(62966003)(106356001)(105586002)(5003600100002)(86612001)(122556002)(19300405004)(19625215002)(2950100001)(40100003)(102836002)(101416001)(15975445007)(64706001)(2900100001)(19617315012)(2420400006)(46102003)(50986999)(33656002)(2656002)(87936001)(54356999)(76176999)(93886004)(97736004)(16236675004)(99286002)(5001960100002)(5002640100001)(4001540100001)(81156007)(110136002)(7110500001)(5001860100001)(76576001)(92566002)(77096005)(189998001)(10400500002)(5001830100001)(5005710100001)(68736005)(10290500002)(3826002)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB291; H:BL2PR03MB290.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_BL2PR03MB2909277FDAF9F0F339D2476AD760BL2PR03MB290namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 22:30:06.9507 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB291
Archived-At: <http://mailarchive.ietf.org/arch/msg/appsdir/V1uAeRl9Ag0KrRMeDNApIFmugHw>
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 22:30:36 -0000

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.


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<mailto: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<mailto:ted.ietf@gmail.com>]
Sent: Tuesday, July 14, 2015 11:18 AM
To: Orit Levin (LCA) <oritl@microsoft.com<mailto:oritl@microsoft.com>>; rtcweb@ietf.org<mailto:rtcweb@ietf.org>
Cc: Eliot Lear <lear@cisco.com<mailto:lear@cisco.com>>; appsdir@ietf.org<mailto: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<mailto: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<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<mailto: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<mailto:lear@cisco.com>]
> > Sent: Thursday, June 25, 2015 12:55 PM
> > To: Orit Levin (LCA); appsdir@ietf.org<mailto: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<mailto:appsdir-bounces@ietf.org>] On Behalf Of Eliot
> Lear
> > >> Sent: Thursday, June 25, 2015 11:44 AM
> > >> To: appsdir@ietf.org<mailto: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<mailto:appsdir@ietf.org>
> https://www.ietf.org/mailman/listinfo/appsdir

_______________________________________________
appsdir mailing list
appsdir@ietf.org<mailto:appsdir@ietf.org>
https://www.ietf.org/mailman/listinfo/appsdir


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb