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

[Ted Hardie <[e-mail]>]

On Tue, Aug 4, 2015 at 3:30 PM, Orit Levin (LCA) <[e-mail]>
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:[e-mail]]
> *Sent:* Tuesday, August 04, 2015 9:42 AM
> *To:* Orit Levin (LCA) <[e-mail]>
> *Cc:* Ted Hardie <[e-mail]>; [e-mail]; [e-mail];
> Eliot Lear <[e-mail]>
> *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) <[e-mail]>
> 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:[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]>
> 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]] On Behalf Of Orit Levin
> > (LCA)
> > Sent: Thursday, June 25, 2015 1:17 PM
> > To: Eliot Lear; [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]]
> > > Sent: Thursday, June 25, 2015 12:55 PM
> > > To: Orit Levin (LCA); [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]] On Behalf Of Eliot
> > Lear
> > > >> Sent: Thursday, June 25, 2015 11:44 AM
> > > >> To: [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]
> > https://www.ietf.org/mailman/listinfo/appsdir
>
> _______________________________________________
> appsdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/appsdir
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>