Subject: Re: [websec] wrt "breaking pins" aka "un-pinning" (breakv, breakc directives; draft-evans-palmer-hsts-pinning-00)

From: =JeffH <[email-masked]>
Date: Mon, 17 Oct 2011 15:09:16 -0700

Hi Trevor & ChrisP,

Trevor Perrin <[email-masked]> noted:
 >
 > In defense of pin-break codes! -
 >
 > On Fri, Oct 14, 2011 at 3:05 PM, =JeffH <[email-masked]> wrote:
 >> So if a purported Known Pinned Host presents a cert chain in the TLS
 >> handshake lacking any keys on the UA's pinned key list, then it could be a
 >> bogus host (eg attacker), and if the UA does a HTTP GET and sends cookies
 >> (as well as receives a response and examines headers (e.g. the UA could be
 >> redirected further afield)) in any case, then this is a (non-trivial)
 >> vulnerability.
 >
 > A better alternative might be to deliver pin-break codes as part of
 > the TLS handshake (e.g. a TLS Extension).  Then:
 >  * Pin-break codes would work regardless of how the pin-break
 > verifiers are set, so pin-break codes could be used with pins set via
 > HSTS header, browser hardcodes, Convergence, DNS, etc.
 >  * Pin-break codes would work with non-HTTP protocols like SMTP or POP.
 >  * Pin-break codes would be retrieved without an HTTP Request,
 > removing the risk noted above.
 >
 > What do you think?

In general, I think we should think about conveying pinning/unpinning in the 
TLS channel in some fashion (which I'd noted at the very end of my original 
msg). And yes, the added benefit of working for other protocols layered on top 
of TLS, rather than just working for HTTP, would seem to be a win (for the 
longer term).

Tho, getting TLS extensions actually implemented and deployed seems to take a 
few forevers.

I wonder about hacking it (conveyance of pinning/unpinning info), for the 
nearer-term, into a cert extension. Then just modifying client apps (e.g. 
browsers) is what's necessary.

 > Pin-break codes might be preferred by site operators nervous about
 > boxing themselves in with pinning, since pin-break codes let the site
 > change its cert chain arbitrarily without being limited by backup pins
 > or waiting for expiration.

Agreed, can see/understand that use case.

Chris Palmer <[email-masked]> followed up..
 >
 > Note that the TLS layer could still abort the connection if the
 > connection doesn't pass the pinning test (i.e. if the connection was
 > made with a server certificate that does not contain any previously
 > pinned public keys).

agreed.

 > Thus, in order to successfully use a breakc, you would still have to
 > serve it with a cert containing a public key you had pinned.
 > (Including, perhaps, your backup pin.)

yes, which has me wondering, as I hope I articulated somewhat clearly, about 
the overall utility of the pin-break-verifier-and-code mechanism, except in the 
particular case where a application server operator wishes to deploy only one 
key/cert and pin to that, cross their fingers, and then fall back on this pin 
breaking mechanism if needed.

 >> In examining the various such situations (aka "disasters") outlined in Sec
 >> 3, it appears that essentially all of them are mitigated if the host
 >> operators allocated a backup server key/cert as advised, and have properly
 >> issued a pin to it, along with their pin to their present operational
 >> key/cert. In this situation, it appears that having the
 >> pin-break-verifier-and-code mechanism isn't strictly necessary.
 >
 > Chris E. and I now agree with this, and are probably going to remove
 > breakc and breakv from the draft specification. Even if they stay,
 > they probably won't appear in the first rev of the Chrome
 > implementation. The thinking is now, "Get the simplest thing
 > implemented, see how people like it, and implement breakc/v if there
 > is demand."

sounds fine to me.

 > This would probably/almost certainly imply that pins expire when the
 > server stops mentioning them in the pins directive (or when max-age
 > expires, whichever is soonest).

Agreed.

=JeffH

---

From: Chris Palmer <[email-masked]>
Date: Mon, 17 Oct 2011 15:21:09 -0700

On Mon, Oct 17, 2011 at 3:09 PM, =JeffH <[email-masked]> wrote:

> Tho, getting TLS extensions actually implemented and deployed seems to take
> a few forevers.

Quite so.

> browsers) is what's necessary.

Your average sys admin is more comfortable telling Apache to send a
particular header with particular text than wrangling openssl(1) to
add various extensions to a certificate.

I don't see a security problem with using the application layer (e.g.
HTTP) to inform the transport layer (TLS), as long as the transport
layer correctly uses the information to exercise policy on subsequent
connections. That's easier said than done in UA implementation code,
of course, but I'm willing to (try to) write that code. I'm not
willing to make sys admins wrangle with X.509 and the openssl command
line. (For example, can anyone here tell me the command line to add a
custom certificate extension to an existing certificate?)

It would be cleaner to have it all in the TLS layer, but
ease-of-deployment concerns dominate. People have a hard enough time
with X.509 as it is.

---

From: Marsh Ray <[email-masked]>
Date: Mon, 17 Oct 2011 17:53:51 -0500

> add various extensions to a certificate.

My understanding is that most people just generate their certs directly
using their CA's web interface and download the result.

On one hand this would suggest that admins will be ill-prepared to set
custom x509 extensions. On the other, we may find that CAs are quite 
receptive to new features which support pinning customers to
themselves.

- Marsh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Oct 2011 23:26:21 -0400

I think that the complexity of pinning and the consequences of getting it
wrong are going to mean that this is something that should only be done by
the very competent and knowledgable or those who hand over administration of
their systems to such. This may be in the form of outsourced provision or
code that does the right thing and makes it hard to do the wrong thing.

I don't think the capabilities/ease of use of currently existing free DIY
cert signer kits should be the criteria to measure against. If this is going
to work people need to be using tools designed for the purpose of managing
the whole thing end to end. Even if that is only a Perl front end on those
fee tools, there is going to need to be something that walks the sysadmin
through.

Rather than look at the extent of the changes required, I prefer to look at
the number of components in the system that need to be touched. I would
rather make two separate modifications to the CA than one to the CA and
another to the Web server. In general, every piece of the system that has to
be touched costs when it comes to deployment.

We are going to have to touch the CA/cert server system to make pinning
work. (Even if only because the CAs are the people who explain to the
typical admin how to make all of this work). So far we do not need to make
changes to the Web server beyond adding static headers which is something
most Web servers already support.

Changing the TLS component of the Web server opens a box labelled 'code' and
gets us into some really long product cycle delays. Like on IIS for
example.

On Mon, Oct 17, 2011 at 6:53 PM, Marsh Ray <[email-masked]> wrote:

> ______________________________**_________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/websec<https://www.ietf.org/mailman/listinfo/websec>
>

-- 
Website: http://hallambaker.com/