Re: [rtcweb] On the topic of MTI video codecs

Eric Rescorla <ekr@rtfm.com> Thu, 31 October 2013 22:45 UTC

Return-Path: <ekr@rtfm.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 DC77311E826C for <rtcweb@ietfa.amsl.com>; Thu, 31 Oct 2013 15:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.753
X-Spam-Level:
X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 qzenbwz0JCKw for <rtcweb@ietfa.amsl.com>; Thu, 31 Oct 2013 15:45:27 -0700 (PDT)
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6646011E8261 for <rtcweb@ietf.org>; Thu, 31 Oct 2013 15:45:26 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id u57so3356693wes.15 for <rtcweb@ietf.org>; Thu, 31 Oct 2013 15:45:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PXBDQ4iNYlxz9K+R5XulDRbP3J2JYeY8u1b+Q7Hd9XU=; b=LwFTsshSdYaAZEaiQ0Gh79MDsX2SUcxaGIAaoQXxa3fQRHdNGh/VYH22JMTK4WIRro r53cYcc70NgP0TOQ6E5e4oXEISgT50Cr4K5oyr2rfTymBIXCEmD+vwAYipld7LMPeQw4 SmSLufuFcTioFEH20KKDMSxOuIB6fjHpH96r2vgmg1OeuQL1v9u6GcJn6a9VRD3FfJ0a /p5hEw6YX0OgYm6n+IwJPlL6vonyPGuf60ws4ynxYNHUo5ttCacHoG1RBdMWb/7+9caF v0UEhnesJXZu4kbldQ5DiHpoLd9Z9k37KldiaRn2DJDe6EU31KodFSHWi73Oc+r0zUCa 8GiA==
X-Gm-Message-State: ALoCoQntjuBKFYCOVa84S1S3QxG6Gb2Hi6xCpENRFKtImSsbuop97z3q9gtFbKo5hylywEsGdx3h
X-Received: by 10.180.24.197 with SMTP id w5mr296517wif.8.1383259522288; Thu, 31 Oct 2013 15:45:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 31 Oct 2013 15:44:42 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <CAL02cgTwJwf27PuxGhhZAZgDN2jguxhNFBNPeJC4W1dwd5jzYA@mail.gmail.com>
References: <527147FF.5010506@nostrum.com> <C72DB04F-F363-45A9-A51F-31900037C239@vipadia.com> <C81F0BD3-F5E6-4E1A-955D-16D55E698BD1@edvina.net> <5272C6C8.3070006@gmail.com> <CABcZeBM6T0a9iLHVujzAiwFi5X5=S0oNK=xR3=FkHM2wi5bngQ@mail.gmail.com> <CAL02cgTwJwf27PuxGhhZAZgDN2jguxhNFBNPeJC4W1dwd5jzYA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 31 Oct 2013 15:44:42 -0700
Message-ID: <CABcZeBOBBu0j97pe2hfyjYCpZQ0QRT2fvyauTgjxkcy_2sTMWw@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary=f46d044286e275626604ea11342a
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, Neil Stratford <neils@vipadia.com>
Subject: Re: [rtcweb] On the topic of MTI video codecs
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, 31 Oct 2013 22:45:33 -0000

Keep reading below.

"Obviously, this only addresses the question of attack from the network,
not malicious binaries constructed by Cisco. I expect that to be addressed
by third parties doing verified builds and comparing the binaries.
Presumably,
one could invent some countersignature mechanism to allow clients to
verify that a specific third party had verified a build."



On Thu, Oct 31, 2013 at 3:36 PM, Richard Barnes <rlb@ipv.sx> wrote:

> On Thu, Oct 31, 2013 at 5:27 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>> On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla <
>> miconda@gmail.com> wrote:
>>
>>>
>>> On 10/31/13 4:10 PM, Olle E. Johansson wrote:
>>>
>>>> On 31 Oct 2013, at 10:02, Neil Stratford <neils@vipadia.com> wrote:
>>>>
>>>>  On 30 Oct 2013, at 17:55, Adam Roach <adam@nostrum.com> wrote:
>>>>>
>>>>>  As Jonathan mentioned earlier, this morning Cisco announced that it
>>>>>> will be open sourcing an H.264 implementation as well as gratis binary
>>>>>> modules compiled from that source and hosted by Cisco for download. Mozilla
>>>>>> will be modifying Firefox to support H.264 by downloading Cisco's binary
>>>>>> module.
>>>>>>
>>>>>
>>>>> It seems like most of the groundwork is being done here for a real
>>>>> codec plugin API which would obviate the need for any particular codec to
>>>>> be selected as MTI.
>>>>>
>>>>> Can we encourage this new codec plugin API to be developed in an open
>>>>> way as part of the standards process and therefore be supported in all
>>>>> browsers? (Enabling for example the addition of VP8 to a browser that may
>>>>> not natively ship with it.)
>>>>>
>>>> I don't agree. The idea was to create a realtime web platform without
>>>> the need for any plugins or downloadable modules. We've had that for ages
>>>> and it is not a good solution.
>>>>
>>>> I am still for a MTI codec or set of codecs so we always can set up
>>>> video calls, regardless of implementation and if it's possible to download
>>>> by policy or network conditions a specific binary.
>>>>
>>> Downloading a binary opens doors for tons of risks, knowing that lot of
>>> carriers do caching or interpose themselves (e.g., it happens very commonly
>>> for dns to redirect you to some adds page when typing an invalid domain),
>>> thus is easy to replace the original source, so a rather complex security
>>> mechanism has to be put in place.
>>>
>>
>> Solely on the security question...
>>
>> I'm not sure what you mean by "rather complex". What I would expect is to
>> have signed
>> binaries. This addresses the question of attack from the network and is
>> how we
>> intend to handle things in Firefox.
>>
>
> You would need something more than that if you don't trust Cisco not to
> tinker with the binaries (no offense).  But even that doesn't have to be
> complicated.  You could just do something like have the software call back
> to the vendor whenever it gets a new binary from Cisco to check that the
> binary it just got is good (say, by comparing hashes).
>
> That way at least Cisco and the vendor would have to collude to introduce
> a bad modification to the binary.  Which is not so bad, because the user is
> already trusting the vendor not to screw them in all sorts of other ways.
>
> --Richard
>
>
>
>>
>> Note that any product that auto-updates (like Firefox and Chrome) already
>> need
>> to have some mechanism for verifying that the things they download are
>> correct.
>>
>>
>>
>>> Even the argument that the code can be compiled and signatures compared
>>> is not really feasible - simply it cannot be done by mobile devices - they
>>> don't have the sdk installed.
>>>
>>
>> I don't see why this would be needed. The containing program (e.g., the
>> browser) doesn't compile, it just does signature verification.
>>
>> Obviously, this only addresses the question of attack from the network,
>> not malicious binaries constructed by Cisco. I expect that to be addressed
>> by third parties doing verified builds and comparing the binaries.
>> Presumably,
>> one could invent some countersignature mechanism to allow clients to
>> verify that a specific third party had verified a build.
>>
>> -Ekr
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>