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

[Alan Johnston <[e-mail]>]

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".

4.3.2.2.There 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.