Re: [rtcweb] No Interim on SDES at this juncture

"Timothy B. Terriberry" <tterriberry@mozilla.com> Mon, 29 July 2013 09:16 UTC

Return-Path: <tterriberry@mozilla.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 BBBE621F9DBE for <rtcweb@ietfa.amsl.com>; Mon, 29 Jul 2013 02:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1]
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 zzXgUYilzOmy for <rtcweb@ietfa.amsl.com>; Mon, 29 Jul 2013 02:16:15 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 41D2721F9E00 for <rtcweb@ietf.org>; Mon, 29 Jul 2013 02:16:15 -0700 (PDT)
Received: from [130.129.33.240] (dhcp-21f0.meeting.ietf.org [130.129.33.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 0C422F225E for <rtcweb@ietf.org>; Mon, 29 Jul 2013 02:16:13 -0700 (PDT)
Message-ID: <51F632D6.1050507@mozilla.com>
Date: Mon, 29 Jul 2013 02:16:06 -0700
From: "Timothy B. Terriberry" <tterriberry@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <CA+9kkMDnjCNXGV0GU7x6gbbZMf4WiEuVvCRY8_Fix5tmdOB-Kg@mail.gmail.com> <AD220324-EEE7-4800-8512-FD7BADA9EC34@oracle.com> <CA+9kkMDY2Z_5_1uYJ1K_ZmrJB2a1-RE7V3aPqNHQg82DyagjCg@mail.gmail.com> <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C78AD@TK5EX14MBXC273.redmond.corp.microsoft.com> <CAL02cgTFSbYSX7v3q37tsjzaPMshyyBroGWr=qmy-HGm82GJFg@mail.gmail.com> <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7EF8@TK5EX14MBXC273.redmond.corp.microsoft.com> <CAL02cgQMkHu-NqEeScT2ObfknJ+3OjXi7Y=7rUJtqeu3CbewMQ@mail.gmail.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <CAL02cgT3KEb0VB9kz=QCe7Mt3oj5tZvZouFe5-Uy90Cmm0H0dQ@mail.gmail.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> <CAL02cgSS1e5zH2YRh4uTb8qxXF5Ng5y8RxRw-bGP5xmQLkiQ+Q@mail.gmail.com> <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com>
In-Reply-To: <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] No Interim on SDES at this juncture
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: Mon, 29 Jul 2013 09:16:21 -0000

Hadriel Kaplan wrote:
> Right, and I'm hoping the Browser vendors can tell us if browsers can safely know whether all the JS running on a given page is from HTTPS or not, and not allow SDES if the JS is not all from (signed) HTTPS.  If not, then I agree that's another negative downside for SDES.  In fact I think it's even a problem for DTLS-SRTP.  I don't know why we'd be ok with using HTTP at all, if we're *truly* concerned about MitM and malicious 3rd party JS attacks.

Yes, this is detectable. As I said at the mic in Beijing, however, this 
is a property that can change at any time, because a page can load 
script from a new, programmatically constructed URL at any point. See 
Section 5.1 of the updated draft-ietf-rtcweb-security-arch-07.

That makes it difficult to design security policy guarantees (it might 
seem "safe" to access a resource when you ask to access it, but very 
difficult to revoke access later when you realize it's not safe). For 
that reason among many others, browsers have been moving to simply block 
mixed content entirely. See 
<https://blog.mozilla.org/security/2013/06/27/mixed-content-blocker-hits-firefox-beta/>;. 
Firefox will release this in August. Chrome already does this. IE has 
prompted users since at least IE 7.