[rtcweb] Security Architecture -07 review

Martin Thomson <martin.thomson@gmail.com> Thu, 25 July 2013 18:33 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E804921F859A for <rtcweb@ietfa.amsl.com>; Thu, 25 Jul 2013 11:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXt+RFPwDubU for <rtcweb@ietfa.amsl.com>; Thu, 25 Jul 2013 11:33:05 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3BF21F90C9 for <rtcweb@ietf.org>; Thu, 25 Jul 2013 11:33:00 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id y10so1307468wgg.28 for <rtcweb@ietf.org>; Thu, 25 Jul 2013 11:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=g9ALw6fBrgg+5RX5W1t0zuloW2Mm/blwTAwAAp8OR3c=; b=Dxiqm07OGlgMEBGCcdWX5KFUHKfLZ+cxWzHfmxr6rADGMp6EXSiFxmzBK5sNDui7Wd j2kBZpiDcuMWDg5DUSRCbZU2DQ+jfqmiNoTgTlx5a6PFqAEsCeAnbJUQGCt5MS1SMNX3 gCX4pqMoeC74gv88yxb584bJhhTyZJ+9uo95SMx+lGNzyOOZPpWGCxP12t4vJn3PK6F3 u0BjQviTjhSFaXxnRHvmoFF1hh9druznsP/k33l4uxKKKG7GTfhlOgOtPPDIyIuhVA4s IrzfjgEMjFwxuson21QKYfrt9la95QHs983I6EyR0BbNS6J2+mkp/W5JwmCXMxzKrCSk nJDg==
MIME-Version: 1.0
X-Received: by 10.194.78.110 with SMTP id a14mr31943295wjx.84.1374777175894; Thu, 25 Jul 2013 11:32:55 -0700 (PDT)
Received: by 10.194.60.46 with HTTP; Thu, 25 Jul 2013 11:32:55 -0700 (PDT)
Date: Thu, 25 Jul 2013 11:32:55 -0700
Message-ID: <CABkgnnWUZXBRneGnRsA9Xo-rrdw7nAsBR+5SL6SRyjbR+Egfgw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [rtcweb] Security Architecture -07 review
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: Thu, 25 Jul 2013 18:33:06 -0000

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.