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

From: =JeffH <[email-masked]>
Date: Thu, 24 Mar 2011 14:27:19 -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

you mean "rogue CA", rather than "reddish pink or red CA", yes?  8^)

 > because the CA is responsible for verifying that the old and new
 > certificates were issued to the same entity.  My understanding is that the
 > [rogue] CA threat model is of paramount importance to the folks interested
 > in certificate pinning, making this approach non-viable for our purposes.

yes.

=JeffH

---

From: =JeffH <[email-masked]>
Date: Fri, 25 Mar 2011 16:21:03 -0700

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

apologies for latency.

In terms of whether HSTS "fundamentally change[s] the TLS server authentication 
model", it's important to note that it is only in the context of 
HTTP-over-TLS/SSL (hence the "H" in the name/acronym), and (for better or 
worse) only applicable for those http clients that implement the policy (it's 
not Mandatory To Implement).

And also HSTS will hopefully be supplanted down the road by some (web) security 
policy approach that's more holistically designed.

In the meantime, there's various Web Applications (nee websites) whose users 
can benefit today from such a relatively easily deployed security policy.

So I feel its reasonable to add a modest feature such as "pinning 
certs/CAs/certType" to a de-jure approach such as HSTS.

=JeffH