RE: Question about time to generate certs

________________________________________
From: Harald Alvestrand [harald@alvestrand.no]
Sent: Sunday, September 06, 2015 12:52 PM
To: public-webrtc@w3.org
Subject: Re: Question about time to generate certs

>On 09/05/2015 04:33 AM, Martin Thomson wrote:
>>> On 4 September 2015 at 19:08, Justin Uberti <juberti@google.com> wrote:
>>> We are about to land ECDSA in Chrome. At that point, I think browser caching
>>> and all other optimizations become meaningless.
>> Key generation is fairly trivial, but not as trivial as retrieving it
>> from storage.  However, I would still recommend key reuse for RSA
>> (sloooow) and for where you actually want to present some sort of
>> stable identity to peers.  In most cases, the default behaviour is
>> probably the best.
>>
>What would you recommend as the best explanation of what the "identity"
>asserted by an ephemeral cert "means"?
>
>I had a discussion with a colleague the other day about this - as far as
>I can tell, an ephemeral cert signed by no trusted party can be used for
>reassurance that the signalling channel and the media channel have
>either not been MITMed or that they have both been MITMed by the same
>attacker.

If the signaling channel has been MitMed, it is trivial to MitM the media - I have running code that shows how easy this is, so there is no reassurance.  Since we allow non-encrypted signaling, this is a major problem, but one that we signed up for when we chose DTLS-SRTP key agreement for WebRTC.

DTLS-SRTP security as it was originally designed relied upon RFC 4474 integrity protection of signaling, but this proved to be undeployable and unusable.

The Identity Provider mechanism in WebRTC attempts to solve this by relying on another 3rd party service, but that is just another avenue for a MitM or compromise (there is no protection if the Identity Provider lies).

There are other solutions to this problem but we've never chosen to seriously look at them in RTCWEB.

Alan


--
Surveillance is pervasive. Go Dark.

Received on Sunday, 6 September 2015 18:22:28 UTC