Re: [rtcweb] Security Architecture -07 review

[Dan Wing <[e-mail]>]

On Jul 25, 2013, at 11:32 AM, Martin Thomson <[e-mail]> wrote:

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

Wrapping the DTLS handshake inside a DH exchange would achieve both goals (preventing a super-cookie from being passively observed, as well as giving key continuity).

-d



> 
>   [...]  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.
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb