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

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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Ted Hardie
> Sent: den 26 februari 2013 00:28
> To: rtcweb@ietf.org
> 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
> 
> On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie <ted.ietf@gmail.com> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb