Re: [websec] [saag] Pinning

[Trevor Perrin <[e-mail]>]

Hi Chris, all,

On Fri, Aug 10, 2012 at 3:20 PM, Chris Palmer <[e-mail]> wrote:
> So ultimately I do think we should decide on either HPKP or TACK, but
> that we should make that decision after there has been some real-world
> deployment experience with both (or, sadly, real-world non-deployment
> of one or both).

My 2c: We should keep exploring both TACK and HPKP.  I'd like to see
both proposals fleshed out, so we can do an in-depth comparison.
We'll try to send a draft-01 in a couple weeks.


> Additionally, HPKP and TACK might converge, more or less. I have plans
> to publish a new HPKP I-D that borrows some of TACK's pin activation
> and expiration ideas, for example.

Awesome, looking forward to it.

There's some things you'll have to grapple with (is pin activation
performed for each key individually, or for the keys as a set?  when
is it performed?  etc.)


> Additionally, one of the main criticisms of HPKP is that it is tied to
> HTTP. I currently don't consider that a huge problem — even though I
> consider TACK's TLS-generic-ness a nice benefit — for several reasons:
>
> * HTTPS is the big, important application that we need to secure right now.

Agreed: TACK's TLS-generic-ness is a nice benefit, but a good solution
for HTTPS is more important than reusability.


> * It's not clear that SMTP over TLS is very beneficial, because you
> can't stop delivery due to pin validation failure (or really even
> regular old X.509 failure).

Pinning for MTA-to-MTA SMTP seems useful.  Since receiving MTAs often
have invalid certificates, they're hard to authenticate any other way.
 If a sending MTA doesn't want to reject connections on pin failure,
it could run in "warn-only" mode.


> * SSH already has PKP. :)

Not proposing to change that.  But a TACK_Extension *could*,
theoretically, be embedded in non-TLS, non-X.509 protocols...  And
TACK *does* have some nice lifecycle features (activation, break sigs,
generations)...


> And finally, as Ben Laurie pointed out, there is also Certificate
> Transparency. I personally consider the "public log" class of
> solutions (of which CT is a leading member, along with Sovereign Keys)
> to be The Real Solution. Pinning-like solutions (including HPKP and
> TACK) are a good, quick fix — as long as they are quick and simple.

I think pinning is likely to coexist or integrate with future trust systems.

For example, Cert Transparency is cool and would help detect bad
certs, but pinning would prevent their use.  I think sites would want
to deploy pinning even in a CT world.

Also, self-asserted pins like TACK and HPKP can be detected by trust
infrastructure (think Convergence or Google Cert Catalog) which
publishes them for auditors to review and for client apps to download.
 So, in a broad sense (pinning, CT, Convergence) are all "public
knowledge" systems which have some similar benefits.

Anyways, quick and simple is always good, but we shouldn't view
pinning as a disposable technology.  (Not that you're saying that, but
just don't want it to be misconstrued).


Trevor