[rtcweb] Review of draft-ietf-rtcweb-security-arch-06

[Alan Johnston <[e-mail]>]

Here is my review of draft-ietf-rtcweb-security-arch-06.

The document has some open issues and clarifications needed, as well as
some editorial and perhaps structural changes.

See below for the details.

- Alan -


Again, lots of RTCWEB, RTCWeb, etc that should be WebRTC.

The document introduction seems to be specific to audio and video WebRTC
sessions.  Later, it becomes clear that the analysis applies to the data
channel as well.  This should be stated clearly up front and any
differences between the two should be explained (i.e. DTLS vs SRTP
encryption).

"SIP or XMPP" - XMPP isn't a signaling protocol but Jingle is, so that is
probably what should be mentioned, but Jingle doesn't use SDP.

"Web sites whose origin we can verify (optimally via HTTPS, but in some
cases because we are on a topologically restricted network, such as behind
a firewall)"  - what is the 2nd case - no verification?  Verification using
something other than HTTPS?

3.1  middle para graph is basically saying that security policy can be
applied after authentication - might be worth stating this after the Dr.
Evil analogy.

4. "Specifically, Alice and Bob have relationships with
   some Identity Provider (IdP) that supports a protocol such as OpenID
   or BrowserID) that can be used to demonstrate their identity to other
   parties." - needs one more ( to parse correctly.

Figures 3 & 4.  Would be better to have IdP1 and IdP2 to make clear that
this can be 2 different providers. Also, Secure WebSockets should be shown
with HTTPS.

In Figures 3 & 4, media is shown as DTLS-SRTP when the media is in fact
SRTP which is keyed with DTLS-SRTP.  In fact, RFC 3711 is not even
referenced, when it should be a normative reference, which is potentially
very confusing and misleading for implementors.  There are many places
where DTLS-SRTP described as if it is more than a key agreement protocol
for SRTP.

Figure 4 is the Trapezoid of the overview and should be referenced as such.

JS is used but not defined.

4.1  The first example in this document of microphone and webcam
permissions is that of a permanent grant.  Is this the model we want to
encourage?  Shouldn't the first mention be of the much safer per call
grant?  Later the per call grant is mentioned, but deep in the document.

4.1 "This message is sent to the signaling server, e.g., by
XMLHttpRequest[XmlHttpRequest] or by WebSockets [RFC6455] "  Sentence is
missing a period.  Do we really mean HTTPS and Secure WebSockets here?

4.1 "This allows the browser to display a trusted element in the browser
chrome indicating that a call is coming in from Alice."  Can this assertion
be made now, prior to the DTLS-SRTP handshake completing?  If this identity
assertion is made at this stage, then a different fingerprint shows up in
the DTLS-SRTP handshake, does the browser chrome then indicate 'sorry, I
made a mistake, it isn't Alice calling'?

There are many cases of using [] instead of () for parentheical text.

4.2 ICE is not defined or referenced in its first occurance.

typo "theor"

5.1 "[[ OPEN ISSUE:  Should this be a 2119 MUST?
   It's not clear what set of conditions would make this OK, other than
   that browser manufacturers have traditionally been permissive here
   here.]] "

   [[ OPEN ISSUE::  Should we be more aggressive about this?]]

Do these issues need to be discussed in a W3C document where browser
expertise might help us do the right thing?

5.2  Do we really expect browsers to have X.509 certificates?  Does anyone
do this with DTLS-SRTP today?  Do browsers have UI to manage these certs?

5.2 The API and UI requirements and elsewhere - should these be in a W3C
document instead of/in addition to this document?

5.2 "Implementations which support some form of direct user authentication
   SHOULD also provide a policy by which a user can authorize calls only
   to specific counterparties."  What is a counterparty?

5.3   ICE-Lite is not defined or referenced.  Since this is a MUST, we need
a normative reference - is it what is described as ICE Lite in RFC 5245
or draft-rescorla-mmusic-ice-lite?

Question:  If a browser has multiple public/private keys, including an
X.509 one, can the JS suggest which one to use for a particular
PeerConnection?

5.5  Again, the media channel is secured using SRTP, not DTLS-SRTP, which
is one way to key SRTP.  In the future, new and better key agreements will
be developed, and if we write all our specs assuming one particular keying
method, then they will become obsolete.

Section 5.6 with Appendix A reads like a completely separate document.  It
is also very hard reading as there are lots of new concepts and ideas.
 Should perhaps this be in a separate document?  The basic security
architecture for WebRTC is unlikely to change, but given that we have no
experience with this IdP system, it seems likely that it will evolve and
perhaps change significantly, which is an argument for a separate document.

5.6.4.2  Is this document defining a new SDP attribute?  Shouldn't this be
done in MMUSIC?

typos "implemementations"  "termnating" "restrcitions"

WebIntents mentioned without reference or explanation.

Missing normative reference: RFC 3711.