[rtcweb] Review of draft-ietf-rtcweb-security-04

Alan Johnston <alan.b.johnston@gmail.com> Sat, 09 March 2013 17:29 UTC

Return-Path: <alan.b.johnston@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0A4AD21F843F for <rtcweb@ietfa.amsl.com>; Sat, 9 Mar 2013 09:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JhMQQZcV8AiO for <rtcweb@ietfa.amsl.com>; Sat, 9 Mar 2013 09:29:26 -0800 (PST)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id E594F21F843E for <rtcweb@ietf.org>; Sat, 9 Mar 2013 09:29:25 -0800 (PST)
Received: by mail-wi0-f182.google.com with SMTP id hi18so262003wib.3 for <rtcweb@ietf.org>; Sat, 09 Mar 2013 09:29:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=hRl6mVpNB1gTckV8FVn26rxm3VChEqRi40oVYX1DZAc=; b=qnaB6hlewRSFrYRDaQEJFJUXMNR93miD3yQVi008mkVCtFavHsoSNcLuHQ8b9jP542 1004PZmAjR6LZv9ZoqOSstB18qdq+NcGqAjrQyNrK+AbZsILmOHgzN5UDBOyDbqwS9pz ouPDHTBqFzNtcnEhjfPA5kDCflMgTVoKEUr3UAkmHoYRCx0SFJ98ClXwDf0ajjrBNfIV c/ClWaaSlCaJ+6ut+dtJvngrZk8ceDc5ySPQwhpD99jkHgNU4lqk7WnnAEhHrWg3xgLW WJk89hYDTGIYQ7jPv1AUg1wR1gkPAWRzvD26e32+/drS4Yj3L+BunxJqI7Bfxz8yTS/0 ZUtQ==
MIME-Version: 1.0
X-Received: by with SMTP id n4mr4413990wia.13.1362850165017; Sat, 09 Mar 2013 09:29:25 -0800 (PST)
Received: by with HTTP; Sat, 9 Mar 2013 09:29:24 -0800 (PST)
Date: Sat, 09 Mar 2013 11:29:24 -0600
Message-ID: <CAKhHsXHc2gb-amXKita_4-fgHVego-Rv+geiq2wk7M61s9=bEg@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="f46d04428f18f7d3a304d7814705"
Subject: [rtcweb] Review of draft-ietf-rtcweb-security-04
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: Sat, 09 Mar 2013 17:29:27 -0000

Here is my review of draft-ietf-rtcweb-security-04.

The draft is mostly ready to progress, with a few corrections noted below.

- Alan -

Abstract and the duplicate text in Introduction: RTC-web turn into either
RTCWEB or WebRTC, with WebRTC being preferred.

"some Web server" - slangy  "a web server"

Figure 1:  might also want to show WebSockets as this is becoming very
common and is mentioned later in the document without much context.  Also,
do we want to show the signaling channel (the one referenced by the W3C
WebRTC spec that transports the SDP offers and answers between browsers)?

JS, popunder, and SWF are not defined in the draft

4.1.2. has a reference to draft-ietf-rescorla-rtcweb-generic-idp.  What is
the status of this draft?

4.3.  RFC 3711 SRTP is not mentioned in the opening paragraph, which seems
strange, since it is the actual protocol providing the COMSEC properties
mentioned, rather then DTLS or DTLS-SRTP for media.

4.3.1. Might be useful to mention that this is sometimes called a "passive
attack" whereas 4.3.2 is an "active attack". are a number of misleading statements about SAS in this
section which should be corrected.  For example:

 "This SAS is designed to be read over the voice channel and if confirmed
by both sides precludes MITM attack."  The SAS is to be *compared* by the
users - reading it out loud is only one possible mechanism.

"Moreover, it is possible for an attacker who controls the browser to allow
the SAS to succeed and then simulate call failure and reconnect, trusting
that the user will not notice that the "no SAS" indicator has been set
(which seems likely)." - I don't quite know what this means.  If SAS is
used, the UI is the browser chrome, so if this is possible, it is just a
badly designed UI not a protocol failure or issue.

"Even were SAS secure if used, it seems exceedingly unlikely that users
will actually use it." - This reads like speculation.  There are users
today using SAS, open source users and commercial users.  One thing is
certain, if we don't provide SAS, then users will not use it.

The whole paragraph is about SAS, but then adds "or fingerprints" in the
last sentence.  There are very significant differences between an SAS and a
fingerprint (which I will call a Way Too Long Authentication String).  If
fingerprints are going to be discussed in this section, then the
differences between an SAS and a WTLAS need to be explained.

Essentially, since we are using DTLS-SRTP, we do not have the capability to
provide an SAS to users, which is a real shame, as it is one usable way to
involve interested users in securing their own media sessions.  Due to the
design of DTLS-SRTP, it is not possible to add one either.