W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2015

Re: Question about time to generate certs

From: tim panton <thp@westhawk.co.uk>
Date: Mon, 7 Sep 2015 05:02:16 +0100
Cc: Adam Roach <adam@nostrum.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <062F0176-C805-4109-AB0D-D05EDBEF4E35@westhawk.co.uk>
To: Eric Rescorla <ekr@rtfm.com>

> On 6 Sep 2015, at 20:38, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
> On Sun, Sep 6, 2015 at 10:27 AM, Adam Roach <adam@nostrum.com <mailto:adam@nostrum.com>> wrote:
> On 9/6/15 11:52 AM, Harald Alvestrand wrote:
> What would you recommend as the best explanation of what the "identity"
> asserted by an ephemeral cert "means"?
> 
> For the "stable identity" situation Martin mentions, it's functionally equivalent to the certs used by SSH.
> 
> Unfortunately, it's somewhat worse than that, for the reasons I just wrote up.
> The Web environment is just much more challenging than the installed app
> environment.
> 


I don’t think it is _that_ different. Your ssh process is probably using an xterm and a x-server to render the characters
which can equally well be intercepted. It comes down to what you trust. 
In the end you have to trust that the site you browse to has done an acceptable job of securing their site and
writing decent javascript. The extent of that trust is up to you.

Note that this is (somewhat) orthogonal to Alan’s point about the signalling, since we are seeing the rise of
signalling-as-a-service providers, so it is plausible that your bank has done a decent job, but the federated 
signalling provider hasn’t.

In this case the stable identity provides ways for the bank to detect MiTM attacks in the signalling service
without necessarily being an IDP.

To answer Harald’s original question, the ephemeral cert does convey some identity, in that it ties together several
different streams. So the far end can be reasonably certain that the data channel and the audio have taken the same
path and have the related security properties. 

Tim.


> -Ekr
> 
> 
Received on Monday, 7 September 2015 04:02:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:46 UTC