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

Eric Rescorla <ekr@rtfm.com> Thu, 31 October 2013 21:50 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 F11F411E8254 for <rtcweb@ietfa.amsl.com>; Thu, 31 Oct 2013 14:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.461
X-Spam-Level:
X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, 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 guT9IjXOCv0R for <rtcweb@ietfa.amsl.com>; Thu, 31 Oct 2013 14:50:48 -0700 (PDT)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id C5CB611E81C0 for <rtcweb@ietf.org>; Thu, 31 Oct 2013 14:50:45 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id z12so3349908wgg.0 for <rtcweb@ietf.org>; Thu, 31 Oct 2013 14:50:45 -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=6RkDpVSr+7UwRFylbRWeuFlLisLTJfwFbrGQwbHcu7w=; b=Hh2vX6hBwTCnsz3/eVT2SSxaVwqr4ZG9Fu+LrOK9B64a+GT3HFqFO5V9KjU7pPfAGL G8d9qe/xk3RoaK7jLROKF/LZLtpICt/4YV5dM1GjdGX1nOeYKeHg84Vth2WCAxeHqOng Uz4kH2hP2DCHfZA/VdPEJVu2bFHL2pMKdnpeu9sZpTWNPEoK3a4o4+DMDOa3ydvHeF9f Ajs4DyEig4aLEsBKtEEBHt7jYULMq+e2Bo57QoNZ1+H8pk5ZOvUD8v5LY0bCBEz5IAX1 /tvvNNTwZtQA3Hu33p3EwTKIZJDGM3yZw/r95gnm6MPESpGiBGhpYo5Jx5HDXuBYnI+a sVOQ==
X-Gm-Message-State: ALoCoQlRIkVcGt0TZXlCLV1sLE/K3ZOHax0cpsNYi6JJq22euIPQ/EbjAiBTNEXi3p/+R/PyZsCt
X-Received: by 10.194.1.139 with SMTP id 11mr4646895wjm.33.1383256245010; Thu, 31 Oct 2013 14:50:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 31 Oct 2013 14:50:03 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <5272CE40.4080908@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> <5272CE40.4080908@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 31 Oct 2013 14:50:03 -0700
Message-ID: <CABcZeBM7_wRcOzGLFCAtgoUnOkaeu2Fakn9w_WB20hmFveg-7Q@mail.gmail.com>
To: Daniel-Constantin Mierla <miconda@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3a8c301e213604ea1071a1
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 21:50:52 -0000

On Thu, Oct 31, 2013 at 2:40 PM, Daniel-Constantin Mierla <miconda@gmail.com
> wrote:

>
> On 10/31/13 10:27 PM, Eric Rescorla 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.
>
>  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.
>
>
> Typically the updates you mentioned are done from the project's sites, so
> that is easier to handle. Now there is a third party involved, requiring
> some sync'ing between Cisco and browser's sites. It's like a
> menage-a-trios, pretty dirty affair.
>

I don't anticipate any problems implementing this in Firefox (and in case
I wasn't clear previously, I'm probably the person who will be responsible
for figuring out how to make it work).



>  I wonder why flash plugin was not loaded this way, it was always free --
> but had to be downloaded/installed explicitly by users.
>

Well, that's not true for Chrome, at least, which ships with Flash, though
I agree that that's somewhat different.



 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.
>
> If we get to 'one could invent some ...' and wait for that, better wait
> for a pure open source video codec.
>

You might be interested in:
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-17



> Mozilla is working in that direction anyhow.
>

That's going to take rather longer than this.

-Ekr



>
> Daniel
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Trainings - Berlin, Nov 25-28
>   - more details about Kamailio trainings at http://www.asipto.com -
>
>