[rtcweb] Security Architecture -07 review

[Martin Thomson <[e-mail]>]

Just a short list of niggles and nits.  I only reviewed the diff.

The abstract has been truncated.

Section 4.1, last paragraph on p11, s/[RFC6455]./[RFC6455].,/

Section 5.1
   [...]  Implementations MUST either
   choose to terminate the call or display a warning at that point.

I don't recall the discussion that lead to this conclusion.  I'm still
in the "stop sending" camp on this.  I understand that browsers
already require machinery that notifies them of when a page
transitions to becoming mixed content, because the lock icon tends to
disappear on gmail all the time.  So the only technical concern I can
think of is the fact that this will appear as though there was a
sudden massive packet loss event.  I believe that's workable, as long
as RTCP and connectivity checks continue.

Section 5.2:
   [...]  Note that
   it is unlikely that browsers would have an X.509 certificate, but
   servers might.

This is a little over-simplified.  1.  Servers will have an X.509, and
that will need to be trusted somehow.  2.  Clients will have X.509
certificates or else DTLS won't work, it's just that it's unlikely to
be trusted for authentication of a domain name.

I hope that we intend to talk about screen sharing at some point.
That seems to be a bit of a big hole here.  Even if all the mechanisms
described are implemented, I don't believe that to be sufficient for
this to be deployed.   I tend to think that there needs to be a way to
either opt-out (or preferably opt-in) of screen sharing.  This
probably crosses into W3C territory a bit too.

Section 5.4:
   [...]  Either such
   enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or
   the JS [...]

The TURN only option at the browser level might be possible, but this
is pretty unrealistic.

Section 5.5:
   Unless the user specifically configures an
   external key pair, different key pairs MUST be used for each
   origin. (This avoids creating a super-cookie.)

The "unless" here is interesting.  Why do you believe that caveat to
be necessary?

On a related note, we had some offline discussions about what it means
to use the same key pair over time for the same site.  Early Firefox
implementations used a new key pair for every RTCPeerConnection,
which, aside from being a little CPU-intensive, tends to make it
impossible to audit calls after the fact.  That is, it is useful to be
able to ask the person you thought you were talking to for their
certificate fingerprint to ensure that you really were talking to that
person.

However, the cookie issue is still a problem.  Removing the
certificate and key pair when cookies are cleared is necessary.

   [...]  However, if Null ciphers are used, that MUST be presented to
   the user at the top-level UI.

At what point did we decide that the Null cipher was acceptable?  I
thought that TLS pretty much prohibited the negotiation of the null
cipher.  I certainly wouldn't want to imply that this is an acceptable
thing to do.