[websec] Feedback on draft-ietf-websec-key-pinning-01

[[e-mail]]

Hi all,
It's good to see the progress in draft-ietf-websec-key-pinning-01. I'm still concerned about the impact of pinning on non-pinned domains, and don't see anything present to warn about or mitigate this. Apologies if I've missed discussion of this on-list/in the archives.

My concern centers on domains which aren't currently secured, and in the current environment (IMHO) reasonably so e.g. news.bbc.co.uk  or theregister.co.uk

With pinning, if they lose control of their DNS*, visitors during that period can be HSTS+pinned to a certificate which the domain owner has no access to, leading them open to long-term denial of service (beyond reclamation of DNS) or extortion.

There's a variant with TLS enabled sites without pinning which could still be pinned to keys which the domain owner doesn't have access to.

There are a few responses to this I can think of:

1. It's 2011/2012... everyone should be using TLS+HSTS+Pinning
2. It's fine - important sites will have decent pull with browser vendors to ship unlock pins...
3. Modify the spec to make the vulnerability smaller

1 may be a valid response, but in that case, I think the spec should call out this potential vulnerability in section 3 and highlight that the only complete mitigation is to go to TLS+HSTS+Pinning. I think it's important to call out to implementors this possibility, and that they might have to deal with something like (2).

2 isn't really a solution and doesn't sit well as inevitably smaller sites won't have as good a pull with vendors and could be disadvantaged. Also, I doubt the vendors really want to get into the game of identifying this game.

My only thought for 3 is to narrow the vulnerability by softening/not enforcing the pin until it's seen multiple times over at least some minimum period of time in which a DNS etc problem is likely to be rectified. There's already a bootstrapping hole, and I don't know that widening it by a small time period is a huge deal.

Cheers,
David

* once your registrar is compromised and nameservers changed, getting a DV cert is trivial for the attacker