Re: Request from WebRTC

On Thursday, November 14, 2013 at 12:06 AM, Ryan Sleevi wrote:
> .setDTLSKey(AES) == ??
> .setDTLSKey(RSA-PSS) == ??
> .setDTLSKey(RSA-ES) == ??
>  
> I see no advantages to using WebCrypto to 'generate' the key.
How else would you do it?  Some other JS API that references the same underlying key generation routines?
  
> What if you generate a WebCrypto key but set the usage as wrap?
>  
>  

Obviously, the intent is that only certain keys will be acceptable for use with WebRTC (likewise with the algorithms above).   So there’s probably some check internal to PeerConnection.setDTLSKey()
  
if (( /* algorithm not in acceptable algorithm set */ ) ||
   ( /* proper key usages not in key.usages */ ) ||
   ( /* key could be accessible to JS (e.g., extractable) */ ) {
  throw RefuseToUseThisKeyException();
}

That doesn’t seem like a reason not to use WebCrypto, any more than the fact that other applications might only be able to use keys with certain properties.

> It seems the only benefit is you like that there's an object called
> Key. Everything else seems... undesired?
>  
>  


Like I said before, there are at least these desirable properties:
-- Key generation
-- Key reference without JS access
-- Key storage without JS access

--Richard

  
>  
> On Wed, Nov 13, 2013 at 10:50 PM, Richard L. Barnes <rbarnes@bbn.com (mailto:rbarnes@bbn.com)> wrote:
> >  
> > 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.
> >  
>  
>  
>