[rtcweb] Comments on draft-ietf-rtcweb-security-06

John Mattsson <john.mattsson@ericsson.com> Fri, 14 March 2014 09:35 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 13ADD1A00E3 for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 02:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PsI0X6O-Ty8R for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 02:35:47 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 1AEAE1A00C6 for <rtcweb@ietf.org>; Fri, 14 Mar 2014 02:35:45 -0700 (PDT)
X-AuditID: c1b4fb25-b7f038e000005d01-cb-5322cd6acf83
Received: from ESESSHC012.ericsson.se (Unknown_Domain []) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2E.55.23809.A6DC2235; Fri, 14 Mar 2014 10:35:38 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([]) by ESESSHC012.ericsson.se ([]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 10:35:37 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Comments on draft-ietf-rtcweb-security-06
Thread-Index: AQHPP2jBbcKLi1qPfU6JnWpSLmUKWw==
Date: Fri, 14 Mar 2014 09:35:37 +0000
Message-ID: <CF488C1C.11409%john.mattsson@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/related; boundary="_005_CF488C1C11409johnmattssonericssoncom_"; type="multipart/alternative"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRmVeSWpSXmKPExsUyM+JvjW7WWaVgg3OP9C3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvOv31gKbnxgqtg2dyJbA+P+Z0xdjBwcEgImEotn53cxcgKZ YhIX7q1n62Lk4hASOMQo8ftnMzuEs4RR4uWEtywgVWwCBhJz9zSwgdgiAuoSlx9eYAexhQWM JNZ1tbKDDBURMJf4MpcdokRPYubzA0wgNouAqsSe841gY3iBSp7uns0MYjMCLf5+ag1YDbOA uMStJ/OZIA4SkXh48TQbhC0q8fLxP1YQWxRo5r1Hc1kg4ooSV6cvh+qtkJi4v5cZYr6gxMmZ T1gmMArPQjJ2FpKyWUjKIOIxEu++7mecBfQBs4CmxPpd+hBhRYkp3Q/ZIWwNidY5c9khSqwl eucJYirxlrg8YTEzhO0gMWXPbSCbC8g+xijxfeNhVoiEkcTnNWdZUTVzgDXfajaD6f06/RAL XO+tn3uZIWqMJCZ9SEbWuoBReBUje25iZk56udEmRmCyOLjlt+oOxjvnRA4xSnOwKInzfnjr HCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBceHRZ/VPhFK3CGfxWU9qfi56VXrKJfm7v6ew mU5IdGqf79koN2NHVJ+/xNGgWElFi/hERjvp3D+6E581zRL6lbNH7lixwcGmPqXmvmszZdos bzzi2f/ol/9mh+fPzhcENmZKzXdzSGxdueZe2NxCkXOTlrSytR8wU+Ys+Jb/7rjgKtY/8+bl K7EUZyQaajEXFScCADRJpkbkAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_2cf1vSU6hI9ZSjqkKF64AG74E8
Subject: [rtcweb] Comments on draft-ietf-rtcweb-security-06
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 14 Mar 2014 09:35:50 -0000

I have reviewed Security Considerations for WebRTC (draft-ietf-rtcweb-security-06)

Seems to be in good shape.




The draft should discuss threats when the users belong to different calling services. There are then two potentially malicious calling services as well as the transport between them.


The draft should make clear how the threats, levels of consent, and chrome indications differ between data channels and media channels. Obviously consent and chrome indicators are needed for accessing mic and camera. Right now the draft mostly talks about consent and indicators for a "call" and says nothing about caller and callee consent and chrome indicators for pure data channels.


A draft discussing threats to a user-to-user communication system should probably discuss unsolicited communication (i.e. SPIT, SPIM) a little bit, not just writing that "prank calls" is out of scope.

3.  The Browser Threat Model

-[s3] "NETWORK ATTACKERS, who are able to control your network"

Should be "the network" or "part of the network"

4.1.  Access to Local Devices

-[s4.1] "In either case, all the browser is able to do is verify and check authorization for whoever is controlling where the media goes."

Should mention that the browser may be able to authenticate the media destination.

-[s4.1] "By contrast, consent to send network traffic is about preventing the user's browser from being used to attack its local network."

   It's also about DoS (which is mentioned in the beginning) and protecting other networks that may have firewalls blocking traffic from Dr. Evil but accepting traffic from you.

-[s4.1.2.1,] "If I grant permission to calling service A to make calls on my behalf, then I am implicitly granting it permission to bug my computer whenever it wants." "Note also that the user interface chrome must clearly display elements showing that the call is continuing in order to avoid attacks where the calling site just leaves it up indefinitely but shows a Web UI that implies otherwise."

The text on chrome indications is also highly relevant for, Even if the user have granted long term consent, the browser should still show when a site accesses mic and camera.

4.2.  Communications Consent Verification

-[s4.2.2] "UDP over DTLS"

Is this used anywhere or just a theoretical example?

4.3.  Communications Security

-[s4.3] "secure against both message recovery and message modification."

Add replay

-[s4.3] "the peer's identity information, which, after all, is only meaningful in the context of some calling service."

Not if authenticated via IdP or PKI.

-[s4.3, 4.3.1, and 4.3.2]

I think the division in "uncompromised during call, later compromised" and "active" is a bad idea. I would strongly recommend restructuring section 4.3, 4.3.1, and 4.3.2 to follow the definitions of "passive attacks" and "active attacks" in RFC 3552. The text could then also:

        - Differentiate between attacks on the signaling plane and the user plane, and clarify where PFS is needed.

        - Differentiate active attacks on the key management vs. active attacks by sending traffic to a recording service.

        - Also consider passive and active attacks from other than the calling service.

        - Make it clear that (in most cases) you need access to both control and user plane data.

-[s4.3] "The calling service is compromised during the call it wishes to attack (often called an "active attack")."

While "active attack" implies "compromised during call" the opposite is not true as a during-call attack can very well be passive.

-[s4.3] "The calling service is non-malicious during a call but subsequently is compromised and wishes to attack an older call (often called a "passive attack")"

Similarly as the above comment "passive attack" does not equate the calling service being non-malicious during the call.

-[s4.3] "We discuss some potential approaches and why they are likely to be impractical in Section 4.3.2."

Section 4.3.2 does not discuss "why they are likely to be impractical"


Fails to clearly describe that the attacker needs access to the media channel and describe how the attacker gets that. If the calling service is compromised it can just include itself it the media path, but otherwise the attacker must intercept the media path.

-[s4.3] "However, it is extremely difficult"

Well theoretically it's simple (authenticate), maybe explain that the difficult part is deployment in the WebRTC case.


Should mention that the retrospective attack requires that the calling service has either saved all the media (not that likely) or that the attacker has captured it beforehand.

-[s4.3.1] "in SDES [RFC4568]), then retrospective attack is trivial."

I would remove trivial. I agree that if you have 1. been able to capture the data by intercepting the communication between the  peers, 2. been able to compromise the calling service, and 3. been able to read the key from the logs, then decrypting is trivial, but 1,2,3 is not trivial.


Should mention that any fingerprint mechanism sent via the calling service (such as the one in DTLS-SRTP) does not help at all (when the call service is malicious).


In the secure media mode, the calling site should not only be forbidden to view and modify the media. It should also be forbidden to send audio to the speakers. Othervise it can still indirectly modify the media.

4.4.  Privacy Considerations


Should mention that there is a trade-off between resetting DTLS certs and key continuity.



-"Westerland" -> "Westerlund"




-"soft phones" or "softphones"

-"xref target="RFC6454"/>"

-First sentence in 4.2.2 is duplicated

-"Use or RTCP"

-"site not work well"

MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

Ericsson AB
Security Research
Färögatan 6
SE-164 80 Stockholm, Sweden
Phone +46 10 71 43 501
SMS/MMS +46 76 11 53 501


This Communication is Confidential. We only send and receive email on the basis of the terms set out atwww.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>