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

[Richard Barnes <[e-mail]>]

On Thu, Jun 20, 2013 at 7:41 PM, Martin Thomson <[e-mail]>wrote:

> On 20 June 2013 16:09, Richard Barnes <[e-mail]> 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