Re: [rtcweb] Working Group Last Call draft-ietf-rtcweb-security

Magnus Westerlund <> Thu, 07 March 2013 09:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AB3D21F8AA6 for <>; Thu, 7 Mar 2013 01:23:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.099
X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0mDnSAE8qxrB for <>; Thu, 7 Mar 2013 01:23:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C3F1221F8A43 for <>; Thu, 7 Mar 2013 01:22:49 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-ae-51385c6809d7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 3A.54.19728.86C58315; Thu, 7 Mar 2013 10:22:48 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 7 Mar 2013 10:22:48 +0100
Message-ID: <>
Date: Thu, 07 Mar 2013 10:22:47 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To:, EKR <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3RjcjxiLQYEWjocWK1+fYLdb+a2d3 YPJYsuQnk8fkx23MAUxRXDYpqTmZZalF+nYJXBkX7y5hLdguV3F60XP2BsYVEl2MnBwSAiYS ex9vZYGwxSQu3FvPBmILCZxklFgxFSjOBWQvY5SYP2UiWIJXQFvi1IS3rCA2i4CKxNW398Ca 2QQsJG7+aASq4eAQFQiWuLlYDqJcUOLkzCdgJSIC6hIz5m8DGyMs4CGx49B2ZohdARLPnz9n BmnlFAiU6NyYBnGOpMSWF+3sIDazgJ7ElKstjBC2vETz1tlQrdoSDU0drBMYBWch2TYLScss JC0LGJlXMbLnJmbmpJcbbWIEhuPBLb9VdzDeOSdyiFGag0VJnDfc9UKAkEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBkaPfcbHLuixhvO3K/YznvglldUTaL9isU7ahlz7vw6n7eTnFVUcCNOf 6bjV/dOtg4u2GBxk3Hh/i+GbHysPKXIKx2xcLFK9S/q+y3653rLK0rn8efv1VFPLUoPnit6d vk7C6P7xkuLkNPs3USsUv8ryT9Z6IJ2d+vBkbmQ9442Ly9q+9O6Py1RiKc5INNRiLipOBABE HIi+FQIAAA==
Subject: Re: [rtcweb] Working Group Last Call draft-ietf-rtcweb-security
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Mar 2013 09:23:05 -0000

EKR and WG,

I have reviewed the security draft (-04) as an individual and have the
following comments.

1. Usage of acronym RTCWEB vs WebRTC. I thought we earlier had a
conclusion that we would use WebRTC as the acronym for the complete
solution? Am I remembering incorrectly?

2. I think the introduction should contain some pointer to the overview
draft for reverse lookup purpose if one stumbles on the document.

3. Section 3.1:
Similarly, while Flash SWFs can access the camera and microphone,
   they explicitly require that the user consent to that access.

Can you please expand the SWF acronym and perhaps add a reference?

4. Section 3.2:
Many other resources are accessible but isolated.  For instance,
   while scripts are allowed to make HTTP requests via the
   XMLHttpRequest() API those requests are not allowed to be made to any
   server, but rather solely to the same ORIGIN from whence the script
   came.[RFC6454] (although CORS [CORS] and WebSockets [RFC6455]
   provides a escape hatch from this restriction, as described below.)

This above looks strange around the first period, which is followed by
RFC6454 reference. If is is a new sentence, the main sentence contains
only a reference.

5. Section 3.2
This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks
   on server B via the user's browser, which protects both the user
   (e.g., from misuse of his credentials) and the server (e.g., from DoS

I think one can make clear that the server one protects are B in the end
of the sentence. Although it reasonably clear from context, I think
writing it like this:

This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks
   on server B via the user's browser, which protects both the user
   (e.g., from misuse of his credentials) and the server B (e.g., from
   DoS attack).

Is clearer.

6. Section
In both of the previous cases, the user has a direct relationship
   (though perhaps a transient one) with the target of the call.

Is it really the "target of the call" or is it the calling service that
the user has a direct relation ship with?

7. Section 4.2.1:

[[ OPEN ISSUE:  Do we need some way of verifying the expected traffic
   rate, not just consent to receive traffic at all.]]

Regarding this issue, I think you could add something which makes this
not required, namely that by requiring congestion control of all flows
established by the browser, the browser tries to avoid persistent
congestion and any overload attack is less effective. The attack is more
in the vain of reducing any competing flows supported rate to a lower
fair share rate, which in worst case is below what is required to
support the service being the target of the attack.

Thus I think the open issue question is a nice to have, but not required

8. Section 4.2.4:

I think this document is missing to discuss the privacy threats beyond
IP location privacy? I think that should be added, especially as we are
addressing some issues we know of.

These other threats that we have discussed are associated with anonymous
calling services and linking and fingerprinting browsers or users with
anonymous calls. The threats we do know exist are for example RTCP CNAME
generation, DTLS certifcates, and API fingerprinting. I think these
needs to be raised as a threat.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: