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

Richard Barnes <rlb@ipv.sx> Fri, 21 June 2013 02:18 UTC

Return-Path: <rlb@ipv.sx>
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 5E41821E80EB for <rtcweb@ietfa.amsl.com>; Thu, 20 Jun 2013 19:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level:
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 hnMSbkUxx2nw for <rtcweb@ietfa.amsl.com>; Thu, 20 Jun 2013 19:18:11 -0700 (PDT)
Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 34C6521E80B0 for <rtcweb@ietf.org>; Thu, 20 Jun 2013 19:18:11 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id k7so8632719oag.23 for <rtcweb@ietf.org>; Thu, 20 Jun 2013 19:18:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=1iYBgiBBOqHMu8m6Z7kBpmjpEpGdviCVt8TS045bA2g=; b=OS0xXxD6FEkZEdXYD3tnc7Wyv68Wo5bJ/PckrbhNmaVqBdLkv2/qLnOxgRmkISkH95 CJWxTLgL4XNOeC93699OqYAjj/y8ky7EpbPwnXCZ77E+Xd0nhnpb+IjPfvS2GgivKSDj wjwm0mOECJvKbLYJhWPruZm3BxpMzJsEvF8pe8JcScpLDltvnnHGFf7JrreLqISftm5W aQ1FPAKIBDwtgiS42yX8TDDG+WvU8pwp2UXv4cYElLxnBf+VSeSmAh3OLgLAQb08jc4x bG2DeNxU0zrboE7VoZQbdDSFwz1FtTie08vzZCctrtXt4uWH3KQExSTgiaqPSNEf2PUS pZjg==
MIME-Version: 1.0
X-Received: by 10.60.144.233 with SMTP id sp9mr5602653oeb.53.1371781090583; Thu, 20 Jun 2013 19:18:10 -0700 (PDT)
Received: by 10.60.26.135 with HTTP; Thu, 20 Jun 2013 19:18:10 -0700 (PDT)
X-Originating-IP: [128.89.255.40]
In-Reply-To: <CABkgnnUV55A7rfE6BZA-a6f7rn=FYdVTAEun1ZaYnnJuo9JZgg@mail.gmail.com>
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> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> <CAD5OKxvMGD=e3rHta9aLRAOAM022V0hzcp6nJbmG+GAxBohS6g@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net> <CAD5OKxs6kbMRhK5S8XYywAbfcEKyBnmBw=7nAgKeLed8iGx-uw@mail.gmail.com> <CAL02cgSG+AntWvyyyGFoQ3zXkZtpd6pVCHfpiCZjSV_3rdj=6Q@mail.gmail.com> <CABkgnnUV55A7rfE6BZA-a6f7rn=FYdVTAEun1ZaYnnJuo9JZgg@mail.gmail.com>
Date: Thu, 20 Jun 2013 22:18:10 -0400
Message-ID: <CAL02cgTZUkvr0cQ0xOyjWS6AEF34j0snh10r5BqRkZqXSbK2Qg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3a8b669d3cc304dfa0acdd
X-Gm-Message-State: ALoCoQmcqFCftTPzcqnBXGXc38fQtgLkSExwinzp9dVK3GFpKgh10x3ffrV7TCTW5C6K83+SP66y
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Fri, 21 Jun 2013 02:18:16 -0000

On Thu, Jun 20, 2013 at 7:41 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 20 June 2013 16:09, Richard Barnes <rlb@ipv.sx>; wrote:
> > If, in addition, the browser does not expose media keys to JS (as is
> > required for SDES), then even an active attacker who hijacks the HTTP
> > connection to inject scripts cannot access the media keys.
>
> That's only true if that attacker were not able to also set the keys.
> I haven't had anyone explain what the API for EKT would look like, but
> one possibility would permit that attacker to set keys (i.e., keying
> would be write-only).  That possibility would be attractive from a
> symmetry perspective - the non-browser can insert new keying, why
> should the browser be prevented from doing so - but I can see how
> implementation of EKT does not strictly require that possibility.
> That would preclude some interesting browser-API-based scenarios
> though.
>

Good point.  I hadn't thought of that.  In order for SDES to work, though,
I would think you would need both getting and setting of keys.

What interesting scenarios do you have in mind?  I wonder whether the group
considers them critical for v1.

In any case, this seems like something where a conservative approach could
be taken at first, then a key access API added later.

--Richard