Subject: Re: [rtcweb] Reminder: Working group last call for draft-ietf-rtcweb-security-arch

From: Colin Perkins <[email-masked]>
Date: Mon, 4 Mar 2013 12:58:20 +0000

Ted,

This draft has a number of places where open issues are noted (e.g., in Sections 5.1 and 5.5, but there are many others). It seems premature to issue a working group last call until those are resolved.

Colin

On 25 Feb 2013, at 23:27, Ted Hardie wrote:
> This is a reminder that there is an ongoing last call for
> draft-ietf-rtcweb-security-arch-06.  Please send comments, including
> those of the "reviewed and no issues" ilk, by March 9th, 2012.
> 
> regards,
> 
> Ted Hardie
> 
> On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie <[email-masked]> wrote:
>> This begins a working group last call for
>> draft-ietf-rtcweb-security-arch.  Please send comments to the list by
>> March 9, 2013.
>> 
>> regards,
>> 
>> Ted, Cullen, Magnus
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Colin Perkins
http://csperkins.org/

---

From: Ted Hardie <[email-masked]>
Date: Mon, 4 Mar 2013 08:43:46 -0800

Hi Colin,

Thanks for reviewing the document.  As you note, there are open
issues; 5.1, for example, has this:

"This is a  deliberate implementation complexity versus security tradeoff.
 [[ OPEN ISSUE::  Should we be more aggressive about this?]]"

As far as I am aware,though, the document in each case includes a
proposal for the Open Issue,
and it is that which would be in a WG document post last-call.  But if
folks looked at the document
and answered the "open issues" within, that would certainly be very
welcome input.

Were there any Open Issues or other points you wanted to comment on directly?

Ted

but there

---

From: Justin Uberti <[email-masked]>
Date: Mon, 4 Mar 2013 15:30:00 -0800

I already sent mail to Eric on this, but one thing that needs consideration
in this draft is the use case identified in section 4.2.7 of
draft-ietf-rtcweb-use-cases-and-requirements-06, i.e. desktop sharing.
Section 5.2 of the security doc covers the requirements for consent for
camera access, but not for desktop access.

On Mon, Mar 4, 2013 at 8:43 AM, Ted Hardie <[email-masked]> wrote:

> > This draft has a number of places where open issues are noted (e.g., in
> Sections 5.1 and 5.5, but there are many others). It seems premature to
> issue a working group last call until those are resolved.
> >
> > Colin
> >
> >
> >

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Mar 2013 15:36:00 -0800

Thanks, Justin.

I have been working on something for this and hope to have some text soon.

-Ekr

On Mon, Mar 4, 2013 at 3:30 PM, Justin Uberti <[email-masked]> wrote:

> I already sent mail to Eric on this, but one thing that needs
> consideration in this draft is the use case identified in section 4.2.7 of

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Mar 2013 17:02:55 -0800

Does the text say: "screen sharing is a bad idea" ?

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 5 Mar 2013 19:42:38 -0800

Or at least recommend against granting long term screen sharing permissions. Spying via audio and video is scary, true, but creepy screen sharing takes it to a new level.

---

From: Oscar Ohlsson <[email-masked]>
Date: Thu, 7 Mar 2013 14:49:20 +0000

Hi Eric,

When reading draft-ietf-rtcweb-security-arch I noticed a couple of things that might be missing:

- According to section 4.3.2.4 in draft-ietf-rtcweb-security there shold 
  be a mechanism to verify that the remote browser has engaged a "secure 
  media mode". This mechanism is not (yet) described in the document.
  
- Except for paragraph 6 in section 4.1, there is not much said about 
  the implications of the "secure media mode".

- An enterprise network with an HTTP proxy may not want external web sites to 
  learn the IP addresses of its hosts using the PeerConnection API. I'm 
  not sure if this kind of attack is relevant or not. If it is then 
  it should be mentioned in Section 5.4. IP Location Privacy.
 
I also have some minor comments on the rest of the document:

- Section 3, 1st paragraph

   The basic assumption of this architecture is that network resources
   exist in a hierarchy of trust, rooted in the browser, which serves as
   the user's TRUSTED COMPUTING BASE (TCB).  
   
  The term "hierarchy of trust" is unclear in this context. Are there other 
  nodes in this hierarchy except for the browser and web server?
  
- Section 3, 2nd paragraph

    This is a natural extension of the end-to-end principle.
	
  Perhaps it's just me but I don't understand what this end-to-end principle is. 
   
- Section 4.3, 1st paragraph

    The total number of channels depends on the amount of
    muxing; in the most likely case we are using both RTP/RTCP mux and
    muxing multiple media streams on the same channel, in which case
    there is only one DTLS handshake.
   
   Won't there be separate handshake for the data channel?
   
- Section 5.4, 1st paragraph
  
    [...] which leaks large amounts of location information,
    especially for mobile devices.
	
   Why are mobile devices different in this aspect?
  
- Section 5.6.4

  The SDP example contains RTP/AVP but I thought SRTP was made mandatory?
  
- Section 5.6.5.1, 3rd paragraph

   All requests from the PeerConnection object MUST contain an "id"
   field which MUST be unique for that PeerConnection object.  Any
   responses from the IdP proxy MUST contain the same id in response,
   which allows the PeerConnection to correlate requests and responses.
   
  Couldn't the browser implementation handle the message routing 
  without the id field?
  
- Section 5.6.5.1.1
  
  The mandatory id field is missing in the example

- Section 5.6.5.2.2

  How is the assertion field transformed into the a=identity attribute? 
  I guess you´re using some form of B64 encoding but this is not expained 
  anywhere.

- Section 5.6.5.2.3

  I think the reason for including request_origin should be explained here 
  instead of in the end of the document.
  
- Section 5.7.1, 3rd paragraph

  WebCrypto API lacks a reference.
  
- Section 5.7.4.5.2

    Any IdP which uses cookies to persist logins will be broken
    by third-party cookie blocking.
   
  Shouldn't it say "Any IdP which uses third-party cookies"?

- Appendix A and B

  Both appendices appear unfinished. For example, ROAP is still mentioned 
  in othe BrowserID example and it's unclear what client credentials 
  Bob uses in the OAuth example.

Regards,

Oscar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ted Hardie
> Sent: den 26 februari 2013 00:28
> To: [email-masked]
> Subject: [rtcweb] Reminder: Working group last call for draft-ietf-
> rtcweb-security-arch
> 
> This is a reminder that there is an ongoing last call for draft-ietf-
> rtcweb-security-arch-06.  Please send comments, including those of the
> "reviewed and no issues" ilk, by March 9th, 2012.
> 
> regards,
> 
> Ted Hardie
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 18:23:55 -0400

I haven't had a chance to write up detailed comments, but my high-level
comment is that it goes into a bit too much detail on how the security
goals are accomplished.

The main thing this document needs to do is lay out the high-level roles in
the process (IdPs, calling sites, UAs) and what security guarantees they
each provide.  It does a good job of that Section 4 and the beginning of
Section 5.

Beginning around Section 5.6, it starts to veer off into technical details.
 Section 5.6 and Section 5.7.4 (and possibly others) should probably be
moved to a separate document, not because I think they're wrong, but
because there are some alternative models to be considered for how to meet
the goals of the security architecture.

--Richard