Subject: [rtcweb] Security Architecture -07 review

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Jul 2013 11:32:55 -0700

Just a short list of niggles and nits.  I only reviewed the diff.

The abstract has been truncated.

Section 4.1, last paragraph on p11, s/[RFC6455]./[RFC6455].,/

Section 5.1
   [...]  Implementations MUST either
   choose to terminate the call or display a warning at that point.

I don't recall the discussion that lead to this conclusion.  I'm still
in the "stop sending" camp on this.  I understand that browsers
already require machinery that notifies them of when a page
transitions to becoming mixed content, because the lock icon tends to
disappear on gmail all the time.  So the only technical concern I can
think of is the fact that this will appear as though there was a
sudden massive packet loss event.  I believe that's workable, as long
as RTCP and connectivity checks continue.

Section 5.2:
   [...]  Note that
   it is unlikely that browsers would have an X.509 certificate, but
   servers might.

This is a little over-simplified.  1.  Servers will have an X.509, and
that will need to be trusted somehow.  2.  Clients will have X.509
certificates or else DTLS won't work, it's just that it's unlikely to
be trusted for authentication of a domain name.

I hope that we intend to talk about screen sharing at some point.
That seems to be a bit of a big hole here.  Even if all the mechanisms
described are implemented, I don't believe that to be sufficient for
this to be deployed.   I tend to think that there needs to be a way to
either opt-out (or preferably opt-in) of screen sharing.  This
probably crosses into W3C territory a bit too.

Section 5.4:
   [...]  Either such
   enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or
   the JS [...]

The TURN only option at the browser level might be possible, but this
is pretty unrealistic.

Section 5.5:
   Unless the user specifically configures an
   external key pair, different key pairs MUST be used for each
   origin. (This avoids creating a super-cookie.)

The "unless" here is interesting.  Why do you believe that caveat to
be necessary?

On a related note, we had some offline discussions about what it means
to use the same key pair over time for the same site.  Early Firefox
implementations used a new key pair for every RTCPeerConnection,
which, aside from being a little CPU-intensive, tends to make it
impossible to audit calls after the fact.  That is, it is useful to be
able to ask the person you thought you were talking to for their
certificate fingerprint to ensure that you really were talking to that
person.

However, the cookie issue is still a problem.  Removing the
certificate and key pair when cookies are cleared is necessary.

   [...]  However, if Null ciphers are used, that MUST be presented to
   the user at the top-level UI.

At what point did we decide that the Null cipher was acceptable?  I
thought that TLS pretty much prohibited the negotiation of the null
cipher.  I certainly wouldn't want to imply that this is an acceptable
thing to do.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Jul 2013 13:47:33 -0700

> be trusted for authentication of a domain name.

Expanding on this a little, with a text proposal.  Sadly, this didn't
turn out to be easy.

OLD:
   In addition, they SHOULD support requests for access that promise
   that media from this grant will be sent to a single communicating
   peer (obviously there could be other requests for other peers).
   E.g., "Call [email-masked]".
NEW:
   In addition, browsers SHOULD ...
(Editorial only)

OLD:
   The semantics of this request
   are that the media stream from the camera and microphone will only be
   routed through a connection which has been cryptographically verified
   (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP
   handshake) as being associated with the stated identity.
NEW:
   An application that requests access that is limited in this way cannot
   access or modify the acquired media or send media to any destination
   other than the specified identity.  The browser will prevent the media
   from being transmitted over a connection which has a cryptographically
   verified identity (see Section !).
(I don't think that it's necessary to do anything more than cite the
appropriate section.  I would have liked to identify a
peer-authentication section here, but Section 5.6 deals only with the
IdP stuff.  If this were my document, I'd promote 5.6 to a new
top-level section and add a new 5.6 that deals with peer
authentication of both forms.  The existing text regarding domain
name-based authentication is light-to-non-existent.

e.g.
5.6. Peer Authentication

   <First paragraph of the current 5.6 is pretty good>

   Establishing the identity of a communication peer requires that DTLS-SRTP
   be used with X.509 certificates being presented by both peers.  Two
mechanisms
   are then possible:

   Identity provider: Most browsers do not customarily have domain names and
      X.509 certificates for those domains.  [The new] Section 6
describes a mechanism
      whereby a cryptographic assertion binding a self-signed X.509
certificate to
      an identity specific to an identity prover can be created and verified.

   Domain name: An X.509 certificate that contains a subjectAltName containing
      a domain name can be verified using the procedures defined in RFC 6125.
      This option is, however, only likely to be feasible for organizations that
      operate servers, since it depends on use of a domain name.

   <existing paragraph>
   Whatever the underlying technology, the general principle is that the
   party which is being authenticated is NOT the signaling site [...]

Feel free to completely rewrite, or ignore this, I'm not across all
the sensitivities here.  I do think that the IdP stuff is big enough
to get its own section.  I actually still think that it's a big enough
concept that a dedicated document would have been a better choice,
still....

Another possibility is to deal with this a little better in Section
3.1, which I note could use a better term than "Other users" to refer
to media/real-time peers.)

REMOVE:
   Note that
   it is unlikely that browsers would have an X.509 certificate, but
   servers might.
KEEP?:
   Browsers servicing such requests SHOULD clearly
   indicate that identity to the user when asking for permission.  The
   idea behind this type of permissions is that a user might have a
   fairly narrow list of peers he is willing to communicate with, e.g.,
   "my mother" rather than "anyone on Facebook".  Narrow permissions
   grants allow the browser to do that enforcement.
(I'm sure about the 2119 SHOULD here.  I think that there are several
ways to think about this.  For the most part,  I believe that there's
no need to make any sort of normative statement.  Absence of an
indication isn't going to disadvantage users, they just lose the
opportunity to learn about restrictions.  Non-normative text that
suggests the UI is a different matter: applications will appreciate
any feature that increases the chance of a user hitting "allow".)

---

From: Dan Wing <[email-masked]>
Date: Thu, 25 Jul 2013 14:54:58 -0700

> certificate and key pair when cookies are cleared is necessary.

Wrapping the DTLS handshake inside a DH exchange would achieve both goals (preventing a super-cookie from being passively observed, as well as giving key continuity).

-d

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Jul 2013 16:12:10 -0700

> Wrapping the DTLS handshake inside a DH exchange would achieve both goals (preventing a super-cookie from being passively observed, as well as giving key continuity).

For passive observers, yes, but I'm not that concerned about them.
After all, they are seeing the flow, so can make all sorts of
inferences based on the flow addressing.

The concern is the first party, who gets the certificate.  Using DH
isn't going to fix that.

---

From: Dan Wing <[email-masked]>
Date: Thu, 25 Jul 2013 17:00:48 -0700

> inferences based on the flow addressing.

But that doesn't mean we should purposefully leak even more information at another layer.

> The concern is the first party, who gets the certificate.  Using DH

Then you're arguing for "endpoint MUST NOT change its certificate".

-d

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Jul 2013 17:12:39 -0700

> Then you're arguing for "endpoint MUST NOT change its certificate".

Nope.  There are reasons to maintain a stable certificate (being able
to audit old calls is helped by this, though a log of fingerprints
used for calls over time might do the same, albeit a little less
transparently; performance is another reason), just as there are
reasons to change the certificate (privacy, mainly an ability to keep
peers from linking calls).

And yes, generally DH > not DH, but I'm not sure the benefits are
huge, depending on what your threat model is.  I was just pointing out
that it doesn't actually help for the cases that I was really
concerned about.  The women's shelter case in particular.

---

From: Dan Wing <[email-masked]>
Date: Thu, 25 Jul 2013 17:34:27 -0700

On Jul 25, 2013, at 5:12 PM, Martin Thomson <[email-masked]> wrote:

No comment on leaking information at other layers?  We just improved the RTCP CNAME to remove its leakage (draft-ietf-avtcore-6222bis), as an example of reducing -- rather than expanding -- personally-identifyable super-cookies.  The DTLS handshake is over the same media path improved by 6222bis.

> concerned about.  The women's shelter case in particular.

Thanks for the explanation.  I concur the public/private key needs a way to be destroyed and a new one generated. 

We could envision a more sophisticated mechanism, based on lots of different criteria, where different public/private key pairs are used and where some are destroyed immediately after certain calls.  For example, I might want to use a public/private key pair for all of my work calls and leave that static (as I want that identity to stick with me) but an ephemeral, one-time-only public/private key pair when not engaging in phone calls related to my work, such as calling my psychologist.

-d

---

From: Martin Thomson <[email-masked]>
Date: Sat, 27 Jul 2013 08:47:33 -0700

> We could envision a more sophisticated mechanism, based on lots of different criteria, where different public/private key pairs are used and where some are destroyed immediately after certain calls…

I believe that we've (EKR and I, I don't know if this made it to
meetings or lists) discussed the need for some application-level
control over these credentials.  I think that the idea was to allow
sites to specify a credential key that would be used to index a table
of credentials.  Of course, every origin would have to use a different
table, which could impose some storage requirements on the browser,
requiring some sort or space management to avoid exploitation.  By
selecting a random credential key for each call (bear with me
regarding terminology, I'm making this up as I go) a site could
effectively create a new set of credentials for that call.

Of course, the site could also choose to generate new credentials for
every call to make it impossible (or at least very difficult) to audit
calls made on that site, if that is something we cared about.  I do
think that in the absence of the identity provider system, that is the
only advantage that DTLS-SRTP brings, so we'd have to be quite careful
here.  I don't know what the right answer is.