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

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
>
>