Re: Request from WebRTC

On Thursday, November 14, 2013 at 1:06 AM, Aymeric Vitte wrote:

> Interesting, I was wondering how WebRTC was handling DTLS between peers, so despite of all security concepts that are opposed to me each time I mention self-signed certificates, all of a sudden, a Web API, WebRTC, is allowed to use them (to switch later to CA-issued certificates... for peers???)
Obviously, if you’re using self-signed certificates, you need some other mechanism for authentication.  WebRTC uses an “Identity Provider” system to layer authentication on top of any certificates in DTLS, including self-signed.

<http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07#section-5.6>
  
> It seems like we are back to certificates, expose certificates and TLS subjects.
>  
> Maybe what is needed finally is to use the WebCrypto Key interface and a "secondary feature" TLS/DTLS secure implementation.
>  
> More generally, I have not looked at the WebRTC ideas to "avoid tracking", but I put together a study case (see at the end of [1]) how WebRTC could potentially be used and insure privacy at the same time, the conclusion is that the whole world knows what you are doing so WebRTC can certainly not be used if you care about privacy, and I don't see any reliable means to encrypt things between peers not involving them sharing a secret (ie know each other, so impossible in practice), that's not the concern of this group but if the conclusion is wrong or limited then please advise separately.
The tracking risk arises when an app use the same public key repeatedly, either across several different peers or multiple times with the same peer.  This is different from the usual fingerprinting, since it’s peer-to-peer fingerprinting instead of server-based.

--Richard

  
>  
> [1]: http://www.peersm.com
>  
> Regards,
>  
> Aymeric
>  
> Le 14/11/2013 04:35, Richard L. Barnes a écrit :
> > The current concept is to focus on keys and self-signed certificates (as current WebRTC implementations are doing), with CA-issued certificates as future work.  
> >  
> > --Richard  
> >  
> >  
> >  
> > On Wednesday, November 13, 2013 at 7:32 PM, Mountie Lee wrote:
> >  
> > > DTLS is based on Certificate which is not yet fully discussed in WebCrypto WG
> > >  
> > >  
> > > On Thu, Nov 14, 2013 at 11:24 AM, 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"
> > > >  
> > > > >
> > > > > 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.
> > > >  
> > >  
> > >  
> > >  
> > > --  
> > > Mountie Lee
> > >  
> > > PayGate  
> > > CTO, CISSP
> > > Tel : +82 2 2140 2700
> > > E-Mail : mountie@paygate.net (mailto:mountie@paygate.net)
> > >  
> > > ======================================= PayGate Inc. THE STANDARD FOR ONLINE PAYMENT for Korea, Japan, China, and the World  
> >  
>  
> -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms