Re: [rtcweb] Security Architecture -07 review

Dan Wing <> Thu, 25 July 2013 21:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 807E421F9287 for <>; Thu, 25 Jul 2013 14:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kc6HGykRMC+J for <>; Thu, 25 Jul 2013 14:55:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B852721F90A7 for <>; Thu, 25 Jul 2013 14:55:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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 ([]) by with ESMTP; 25 Jul 2013 21:55:00 +0000
Received: from ( []) by (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 <>
In-Reply-To: <>
Date: Thu, 25 Jul 2013 14:54:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.1508)
Cc: "" <>
Subject: Re: [rtcweb] Security Architecture -07 review
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Jul 2013 21:55:07 -0000

On Jul 25, 2013, at 11:32 AM, Martin Thomson <> 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).


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