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