Re: [rtcweb] Security Architecture -07 review

Dan Wing <dwing@cisco.com> Thu, 25 July 2013 21:55 UTC

Return-Path: <dwing@cisco.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 807E421F9287 for <rtcweb@ietfa.amsl.com>; Thu, 25 Jul 2013 14:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 Kc6HGykRMC+J for <rtcweb@ietfa.amsl.com>; Thu, 25 Jul 2013 14:55:03 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B852721F90A7 for <rtcweb@ietf.org>; Thu, 25 Jul 2013 14:55:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3618; q=dns/txt; s=iport; t=1374789300; x=1375998900; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=pR01V+XK3i26tqiYY+FvGnBmzcKAzUkvxG9BwRohTwc=; b=icnpRLqjUlzAgrMBeey/L9HUda2aE8Wkc/hnRsP2oMrRVNJUL7pGDeO/ AS8B7dD8IBbkJhkjJu9zZcHgwPT3F5TsbGACtrCvqhlPymY3yrolVJhOt n9GnPoluLd2KvBvKEDkMGMVWjtZMPYe2UexWFmnyHaOklDQUKhhI1VRW7 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFAJad8VGrRDoI/2dsb2JhbABagwY1vjGBFxZ0giQBAQEDAQEBATc0CwULCxI0IQYiDgYTh34DCQUNsCINiFoEjRWCNTMHgxJuA4kqjEyBaYwnhSaDNBw
X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208";a="87223838"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 25 Jul 2013 21:55:00 +0000
Received: from sjc-vpn7-549.cisco.com (sjc-vpn7-549.cisco.com [10.21.146.37]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6PLsx0m019089; Thu, 25 Jul 2013 21:54:59 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <CABkgnnWUZXBRneGnRsA9Xo-rrdw7nAsBR+5SL6SRyjbR+Egfgw@mail.gmail.com>
Date: Thu, 25 Jul 2013 14:54:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D96D0971-E3A7-4E96-B3F4-83C2044252B7@cisco.com>
References: <CABkgnnWUZXBRneGnRsA9Xo-rrdw7nAsBR+5SL6SRyjbR+Egfgw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1508)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [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 21:55:07 -0000

On Jul 25, 2013, at 11:32 AM, Martin Thomson <martin.thomson@gmail.com> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb