Subject: [websec] HSTS: pinning certs, other changes to TLS server authentication

From: Matt McCutchen <[email-masked]>
Date: Wed, 23 Mar 2011 23:31:03 -0400

The following observations were made on EFF's SSL Observatory list
(https://mail1.eff.org/pipermail/observatory/2011-March/000086.html):

On Wed, 2011-03-23 at 12:56 -0400, Matt McCutchen wrote:
> HTTP Strict Transport Security does not pin the cert (it only
> prevents the user from accepting bad certs), so it is exposed to CA
> compromises.  SSH is not.

On Wed, 2011-03-23 at 12:00 -0600, Hodges, Jeff wrote:
> Yes, as presently specified and implemented in it's _draft_ form.
> 
> This could change. [...]
>
> Also, HSTS is arguably an intermediate-term (and specific-to-http)
> approach to the more general issue of network application
> advertisement of security policy. I.e. future work may supplant it.

On Wed, 2011-03-23 at 14:08 -0400, Matt McCutchen wrote: 
> Understood.  But I wouldn't propose to change that.  HSTS is the wrong
> place to fundamentally change the TLS server authentication model.

On Wed, 2011-03-23 at 12:24 -0600, Hodges, Jeff wrote: 
> I nominally disagree with the latter for various reasons, but we
> should discuss on websec@

Jeff, if you had something more to say, I invite you to say it.

-- 
Matt

---

From: Adam Barth <[email-masked]>
Date: Wed, 23 Mar 2011 20:36:32 -0700

> Jeff, if you had something more to say, I invite you to say it.

Thanks for forwarding the thread.  There have been a bunch of people
asking for the ability to pin a certificate (or a CA certificate)
using HSTS.  In light of recent events, that's sounding more and more
like something we should consider.

Adam

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 23 Mar 2011 23:54:49 -0400

> like something we should consider.

Maybe.  Pinning certs is a stopgap; it obviously doesn't work on the
first connection, and it places potentially significant operational
constraints on the web site.  I have a hard time seeing it as a step
toward a coherent server authentication scheme that solves the problems
we are facing today.  But it may be a useful thing to do in light of the
typical temporal and spatial scope of MITM attacks.  (Can anyone comment
on this?)

-- 
Matt

---

From: Thomas Roessler <[email-masked]>
Date: Thu, 24 Mar 2011 13:03:49 +0100

On 24 Mar 2011, at 04:54, Matt McCutchen wrote:

> we are facing today.

Stephen Farrell looked at parts of the problem a while ago and came up with a mechanism for cert switch-overs that he documented in RFC 5697.  Perhaps useful here.

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 24 Mar 2011 20:04:09 +0000

Hm, using a http header makes pinning a cert quite difficult, plus you
still have the trust on first use.
However HSTS is easy to deploy and will give improved security quickly
(even without the pinning).

As has been mentioned on the list earlier, there are considerations for
association of cert with protocol and domain using DNSSEC - though this
is a complicated matter.
Please take a look at dane: https://datatracker.ietf.org/wg/dane/charter/

BR, Tobias

---

From: Adam Barth <[email-masked]>
Date: Thu, 24 Mar 2011 13:42:42 -0700

> Stephen Farrell looked at parts of the problem a while ago and came up with a mechanism for cert switch-overs that he documented in RFC 5697.  Perhaps useful here.

Thanks for pointing out this RFC.  Unfortunately, this approach
doesn't work in the "rouge CA" threat model because the CA is
responsible for verifying that the old and new certificates were
issued to the same entity.  My understanding is that the rouge CA
threat model is of paramount importance to the folks interested in
certificate pinning, making this approach non-viable for our purposes.

Adam

---

From: Thomas Roessler <[email-masked]>
Date: Thu, 24 Mar 2011 22:31:47 +0100

On 24 Mar 2011, at 21:42, Adam Barth wrote:

> issued to the same entity.

So, let's look at the threat model for a second.

Do we assume that any CA can turn rogue at any time, or do we assume that a CA not otherwise used by the site will roguely issue certificates?

The first threat model is, of course, stronger.

---

From: Adam Barth <[email-masked]>
Date: Thu, 24 Mar 2011 14:39:45 -0700

> The first threat model is, of course, stronger.

My understanding is that different folks care about different threats.
 Some folks are happy with CA pinning, which implies the latter, but
others are much excited about leaf certificate pinning, which implies
the former.

Personally, I would be nice if we could handle the pinkish CA problem
and the leap-of-faith authentication use cases with one mechanism.
Perhaps DNSSEC is that mechanism, but maybe there's another approach
that would work sooner.

Adam