Re: Request from WebRTC

Reopening this one, the project mentioned below is moving to WebRTC, the 
draft specs are there [2]

What was the conclusion of this thread?

I have read it several time and still didn't get exactly what was the 
difficulty to handle the keys for DTLS à la WebCrypto.

I  could not read the latest draft due to the mail I just sent, but [2] 
does raise some questions and I don't think it's currently possible with 
the WebCrypto API, using generatKey with RSA:

- how can I get the public key fingerprint?
- how can I get the public key modulus?

Regards

Aymeric

[2] 
https://github.com/Ayms/node-Tor#anonymous-serverless-p2p-inside-browsers---peersm-specs

Le 14/11/2013 10:14, Richard L. Barnes a écrit :
>
> 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
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms