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

[Chris Palmer <[e-mail]>]

On Fri, Oct 14, 2011 at 3:05 PM, =JeffH <[e-mail]> wrote:

> In order for this "un-pinning" pin-break-verifier-and-code mechanism to
> generally work, the UA still connects and and makes an HTTP request and
> reads response headers.

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

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

However:

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

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