Re: Request from WebRTC

On Wednesday, November 13, 2013 at 8:40 PM, Ryan Sleevi wrote:

> On Wed, Nov 13, 2013 at 7:39 PM, Eric Rescorla <ekr@rtfm.com (mailto:ekr@rtfm.com)> wrote:
> >  
> >  
> >  
> > On Wed, Nov 13, 2013 at 7:24 PM, Ryan Sleevi <sleevi@google.com (mailto:sleevi@google.com)> wrote:
> > >  
> > > On Wed, Nov 13, 2013 at 5:53 PM, Richard L. Barnes <rbarnes@bbn.com (mailto:rbarnes@bbn.com)>
> > > wrote:
> > > > For those who might not have been following WebRTC, they are enabling
> > > > browser-to-browser real time communications, using JavaScript.
> > > >  
> > > > The good news is that all WebRTC communications are encrypted with keys
> > > > negotiated using DTLS (using either SRTP or the DTLS for encryption).
> > > > These
> > > > keys are bound to user identities by way of identity assertions passed
> > > > in
> > > > SDP [draft-ietf-rtcweb-security-arch]. The challenge is that WebRTC
> > > > apps
> > > > want to be able to control what keys are used in the DTLS negotiation.
> > > >  
> > > > The overall concept is that the app will be able to impose a key on the
> > > > DTLS
> > > > session, using something like a setDtlsKey() method. The question is:
> > > > Can
> > > > WebRTC use WebCrypto Key objects to represent keys used for DTLS?
> > > >  
> > > > It appears that the answer to this question is “yes”. The app/key
> > > > separation provided by the WebCrypto API provides the layer of
> > > > separation
> > > > that is needed. However, the WebRTC layer needs some additional
> > > > metadata
> > > > about the key:
> > > > -- Whether the key was ever accessible to JS
> > > > -- Limitation of the key to usage with DTLS
> > > >  
> > >  
> > >  
> > > These two statements make me think that WebCrypto is not the right fit for
> > > them.
> > >  
> > > It is, in essence, stating "Were these keys ever Web Crypto keys"
> >  
> >  
> > Hmm.... That seems like sort of a limited view.
> >  
> > We want to:
> >  
> > 1. Create keys
> > 2. Push them around
> >  
> > Why isn't that a legitimate use of WebCrypto?
> >  
> > -Ekr
>  
> You want to:
> 1. Create keys with an API
> 2. Know whether keys were used with this API
> 3. Push them around without using that API.
>  
> Seems a bit of an odd use case.
>  
> It also seems, from the use case, to revisit the whole notion of key
> discovery, which may carry UI implications, etc.
>  
> But again, perhaps I don't fully understand what WebRTC is asking?
>  

The lifecycle is:
1. generateKey() - create keys
2. Store in IndexedDB for future use - shove it into storage
3. peerConnection.setDtlsKey() -  shove it into the DTLS channel
*. Ensure that the key isn’t used with any other WebCrypto methods.

So maybe it’s a little weird in that the ultimate use is through the PeerConnection API and not WebCrypto.  But the overall WebCrypto Key construct provides value by providing:
-- A way to generate keys
-- A way to safely store keys
-- A way to let JS manipulate keys without direct access

By my count, that’s 3 advantages to 1 weirdness.

--Richard



  
>  
> >  
> > > >  
> > > > The proposal is to add information to the WebCrypto Key object to encode
> > > > these metadata.
> > > >  
> > > > This email is intended to be a summary, with more detail to be provided
> > > > in
> > > > discussion tomorrow. The main question for now is whether this seems
> > > > like a
> > > > current-API thing or a future-API thing.
> > > >  
> > > > I would suggest that it is an issue for the current API, because (1) the
> > > > proposed changes are small, and (2) if this is punted to a future
> > > > version,
> > > > then WebRTC will likely come up with an alternative solution.
> > > >  
> > > > Thanks,
> > > > --Richard
> > > >  
> > >  
> > >  
> > > Seems like a never-API to me, based on your summary, but perhaps I'm
> > > missing important context.
> > >  
> >  
> >  
>  
>  
>