Re: Question about time to generate certs

On Sun, Sep 6, 2015 at 9:52 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> 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.
>

The fingerprint in the signaling channel binds the signaling channel to
the media negotiation, so this means as long as you have confidence
in the signaling channel, you can have confidence in the security of
the media.

As we've discussed extensively, in the absence of isolated media
(http://w3c.github.io/webrtc-pc/#isolated-media-streams)
you can only have a very limited degree of confidence in the security
of the media over and above this point, since the site JS can access
and/or monitor the media traffic in the browser regardless of whether
the media channel itself is secure. So, for instance, you could be
connected to the right person but a malicious site could be making
a copy of the media and sending it to itself as well [0].

If you *do* have isolated streams, then there are a number of options
available to protect you from the site:

1. The Identity mechanism, which can be linked to a third-party IdP or
   (because it's domain scoped) can be operated by the domain itself.
2. If the site uses a stable certificate (as Adam suggests) then the
  user can check the peer's fingerprint
(https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#section-5.5
though I don't believe Firefox or Chrome currently supports this. I've
just filed a bug for Firefox to add this feature).

One major difficulty with any long-term identity continuity mechanism (as
in #2 above)
is that all the browser knows about the nominal identity of the counterparty
is told it by the site. This creates a lot of opportunities for the site to
make
MITM attacks look like you're actually connecting to the same user with
a new device (e.g., they erased cookies) or a different user with a very
similar name. In that case, you might get a user indicator that fingerprints
hadn't been verified (if the browser was much much more aggressive about
that than it is now) but you wouldn't get the kind of "you may be being
attacked" indicator that SSH gives, so the protection against attack is
significantly weaker.

-Ekr

[0] It's certainly possible that WebRTC sites would deliver the JS over a
secure channel and the signaling over an insecure one, but that's not
the common case, since generally the signaling is just done over XHR.