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

["Orit Levin (LCA)" <[e-mail]>]

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:[e-mail]]
Sent: Tuesday, July 14, 2015 11:18 AM
To: Orit Levin (LCA) <[e-mail]>; [e-mail]
Cc: Eliot Lear <[e-mail]>; [e-mail]
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) <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Orit Levin
> (LCA)
> Sent: Thursday, June 25, 2015 1:17 PM
> To: Eliot Lear; [e-mail]<mailto:[e-mail]>
> 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:[e-mail]<mailto:[e-mail]>]
> > Sent: Thursday, June 25, 2015 12:55 PM
> > To: Orit Levin (LCA); [e-mail]<mailto:[e-mail]>
> > 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Eliot
> Lear
> > >> Sent: Thursday, June 25, 2015 11:44 AM
> > >> To: [e-mail]<mailto:[e-mail]>
> > >> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/appsdir

_______________________________________________
appsdir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/appsdir