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

[Chris Palmer <[e-mail]>]

On Sun, Dec 11, 2011 at 5:03 AM,  <[e-mail]> wrote:

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

How do DNS registrars handle theft and extortion now? Does pinning
significantly change the dynamic of the scam? It seems to me like
pinning somewhat increases the visibility and detection risk of
theft/extortion, but I admit I don't know much about this scam
phenomenon. The victim must do more than just get the registrar to fix
the DNS, they must also get the private keys for the falsely-pinned
public keys. But the attacker has to get a certificate, which involves
tricking both a registrar and a CA, and paying the latter.

(Since UAs MUST only note pins received over an error-free TLS
connection, the attacker must have received a certificate for the
domain name they stole, signed by a trusted certification authority.
Obviously, that is not impossible (or even difficult, as you note).
Importantly, due to the need for a CA-signed cert, the attack creates
a "paper" and money trail. If it happens often, the internet community
will come to know which CAs are not checking for domain theft, and we
can start to un-trust those CAs. And we can ask them to tell us what
they know about the attackers who bought the certs.)

This puts a bit of upward quality pressure on CAs. For example, maybe
DV issuers could look more closely into the history of the domain's
ownership before issuing the certificate: Has the new owner owned the
domain for one day? Maybe we should call the technical contact who
previously owned it for three years up until yesterday? Has the
registrar had a rash of domain theft lately? This is good for
everyone: internet users, internet site operators, and the CAs and
registrars who work hard to be trustworthy. Pinning makes your choice
of CA matter again.

> 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

Yes to (1) and (3), and like you I don't like (2). As a browser
engineer, I don't want to be handling support emails from people
who've had their domains hijacked — that won't scale — and internet
security must be available to everyone.

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

Ok, I'll come up with some text.

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

Because the bootstrapping hole is so much smaller with pinning than
without, I agree that we have some headroom to play with. Requiring a
minimum time period might not be a bad idea. What would it look like?
"UAs MUST note the same set of pinned public keys for 168 hours (7
days) before treating the host as a Known Pinned Host and requiring
Pin Validation." ?

Does anyone have any data on domain theft and extortion? How often
does it happen, how long does it last, how much is the ransom, et c.?