Re: WebRTC Certificate Management - a plea to NOT use Web Crypto

> On 8 Jan 2015, at 07:14, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> Den 07. jan. 2015 19:18, skrev Martin Thomson:
>> On 7 January 2015 at 10:16, Justin Uberti <juberti@google.com> wrote:
>>> initial setup:
>>> key = RTCGenerateKey();
>>> serialize(key, storage);
>>> 
>>> placing a call:
>>> key = deserialize(storage);
>>> pc = new RTCPeerConnection({dtlsKeys: key});
>> 
>> 
>> As I understand it, we probably wouldn't want to call it a key in that
>> case.  "credentials" might be closer to what Ryan is suggesting.
>> 
> 
> Note - I think the concept of identity is somewhat orthogonal to the
> keys question.
> 
> As I understand it, the common case is one of:
> 
> - Anonymous calling: the correspondent doesn't care who the other side
> is, so no identification is needed.
> - Identified calling: there's some chain of evidence linking the crypto
> keys used for the call to some mutually-known identity (probably via an
> identity provider).

Just to note that there are quite a few sub-cases of Identified calling.

I’d like some way of validating that when I call my bank I am talking to
an authorised bank agent, checking that the cert offered over DTLS corresponds
with a known public (pinned?) web certificate seems like a reasonable way
to do it. That probably means explicit support for X.509 - not just a generic identity
and it needs to be something a middle box can handle on behalf of a group 
of agents.

I’ve been messing with a security mechanism for yopet.us <http://yopet.us/> that depends on the
current chrome behaviour of offering the same cert each time the same site
invokes webRTC. (in essence it permits auto answer on calls from peers that have
been previously ‘seen’ and ok’d). I’d hate to see that feature go. 

> 
> In both cases, the actual crypto keys used can change between calls, and
> the implementations so far have simply generated them anew for each call.
> 
> The two arguments I have heard for key persistence are:
> 
> - Supporting continuity of identity for the anonymous case. The most
> compelling case (as I see it) here is page reload; one would want to
> re-establish a connection on page reload without giving an attacker the
> opportunity to insert itself, even when the call is anonymous.
> 
> - Avoiding key material generation, which can be expensive for
> limited-power devices.
> 
> Which cases did I miss?

Nothing from the big picture - I just want to add some flesh to a rather theoretical 
discussion. 
We run the risk of creating a hyper-abstracted spec with so many possible implementations
that none of them are actually secure. I’d like to see clear guidance on the recommended
implementation and usage strategies of this key element of webRTC’s security, not an
abstract framework where we all get to make our own security errors :-)


Tim.

> 
> 
> 
>