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

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