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

Oscar Ohlsson <oscar.ohlsson@ericsson.com> Thu, 07 March 2013 14:49 UTC

Return-Path: <oscar.ohlsson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121D821F8D52 for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 06:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTn4cuZW1rEQ for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 06:49:23 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E07A121F8D45 for <rtcweb@ietf.org>; Thu, 7 Mar 2013 06:49:22 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-69-5138a8f13436
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B9.8C.19728.1F8A8315; Thu, 7 Mar 2013 15:49:21 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 15:49:21 +0100
From: Oscar Ohlsson <oscar.ohlsson@ericsson.com>
To: "EKR (ekr@rtfm.com)" <ekr@rtfm.com>
Thread-Topic: [rtcweb] Reminder: Working group last call for draft-ietf-rtcweb-security-arch
Thread-Index: AQHOE6+18fICFMHWHUySsbPOSiaetZiaXJBg
Date: Thu, 7 Mar 2013 14:49:20 +0000
Message-ID: <C643F355C8D33C48B983F1C1EA702A45090DEA@ESESSMB301.ericsson.se>
References: <CA+9kkMATiwiFNyq3awr-EHwnWb3+ZEsP+Omgiwdev=8swgMrAQ@mail.gmail.com>
In-Reply-To: <CA+9kkMATiwiFNyq3awr-EHwnWb3+ZEsP+Omgiwdev=8swgMrAQ@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvje7HFRaBBm8XWFqseH2O3WLtv3Z2 ByaPJUt+MnlMftzGHMAUxWWTkpqTWZZapG+XwJXxc/sxtoL/ihXtrV9YGxhPSnUxcnJICJhI /NnzghHCFpO4cG89WxcjF4eQwCFGiRnbdzNDOIsZJXZt+sIEUsUmYCBx6/5JFhBbREBd4uvE k+wgNjOQfWfxOTBbWCBWYteXV1A1cRJTF51hhLCNJHbuPA9Uw8HBIqAicfGgLEiYV8BbouHA RbBWIYEAib3XzrKB2JwCgRKvH99gBbEZBWQl7n+/xwKxSlzi1pP5TBBHC0gs2XOeGcIWlXj5 +B8rhK0osfNsOzNEvZ7EjalT2CBsbYllC18zQ+wVlDg58wnLBEaxWUjGzkLSMgtJyywkLQsY WVYxsucmZuaklxttYgTGyMEtv1V3MN45J3KIUZqDRUmcN9z1QoCQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGxuY2qZSwmvWnel3Vb3x4rBL16lXC6vaENUx92136LQ6/rLy6t0w6xV7o5qpH df8EvB+5J9xnv9765ctbrYTvx66H2xXXM928vf5NyWau/L3TTR22uwSzb4g5dIBJ4ski3s8n RNIWO0fH3fX7tVlgchavw7Q1G3Qk+n7KfavbxtUgOP2q1nRODiWW4oxEQy3mouJEAMMrkSRf AgAA
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Reminder: Working group last call for draft-ietf-rtcweb-security-arch
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2013 14:49:24 -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: 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