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

From: [email-masked]
Date: Sun, 11 Dec 2011 13:03:31 +0000

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

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 11 Dec 2011 16:38:30 -0800

Greetings again. Alexey asked me to review draft-ietf-websec-key-pinning with an eye towards which areas are likely to need more work. I hope the following comments are helpful.

- There needs to be an early balancing the advantages of pinning versus the disadvantages. A description of the possible downsides should be at least partially listed in Section 1, with a pointer to the Security Considerations.

- Some of the significant disadvantages of pinning are not covered. The biggest of these (although I could be wrong) is that an MITM can start using the pinning header with a long max-age before the "real" site has used the pinning header. When the user finally gets to the "real" site, they will not connect to it because of the MITM's pin, giving the MITM a second attempt to come back later. There are probably some other nasty consequences of this. 

- While hash agility is a good thing, the current draft's way of doing this is not the right way. I propose that it instead be changed to "must be sha-256 or sha-384, and later algorithms can be added only by an RFC updating this document".

- The first paragraph of Section 3 should have its own sub-head to clarify that it is not superior to the text in Section 3.1. But, more importantly, Section 3 needs to list the areas where this protocol gives an MITM better attacks than they have now, and should list those first.

Early nit: The first paragraph of Section 1 makes it sound like the pinning header "does not scale"; this is clearly not what is intended.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Dec 2011 00:53:56 +0000

One other thing...

I guess I wonder if the "ni" URI scheme thing [1] is really
useful for this or not. That was after all the reason for
the earlier discussion on this list. (I think.)

Note that I don't really mind if the answer is yes or no. I
do think that one way to use URIs to name things via hash
function outputs is a good thing, and that two or more ways
to do that would be a bad thing, but not all uses of hashes
to identify things need to use URIs and I'm not sure which
analysis applies here.

In any case, be good to decide that too.

S.

[1] http://tools.ietf.org/html/farrell-decade-ni-00

On 12/12/2011 12:38 AM, Paul Hoffman wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 Dec 2011 16:57:34 +0200

> - Some of the significant disadvantages of pinning are not covered. The biggest of these (although I could be wrong) is that an MITM can start using the pinning header with a long max-age before th…

Section 2.3 does say that pins must only be noted if they come over an error-free HTTPS connection, where the chain contains the pinned SPKI. So the MITM would have to be able to take over the DNS (at least for a while) as in the attack described by David on 11-Dec.
Maybe we can mitigate this with a version of this header (or another one) that says "no pins for the next x seconds"

> - While hash agility is a good thing, the current draft's way of doing this is not the right way. I propose that it instead be changed to "must be sha-256 or sha-384, and later algorithms can be ad…

A year from now, "sha-256" is going to be ambiguous. Better to say "sha2-256".

> Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Dec 2011 07:06:12 -0800

> Section 2.3 does say that pins must only be noted if they come over an error-free HTTPS connection, where the chain contains the pinned SPKI. So the MITM would have to be able to take over the DNS…

I don't agree that the MITM must control the DNS for this attack to work. As long as the MITM can intercept the TLS handshake, and the client isn't doing OCSP (or the MITM intercepts that too), using a rogue cert works; thus the rogue pinning works as well.

> Maybe we can mitigate this with a version of this header (or another one) that says "no pins for the next x seconds"

That still doesn't deal with the site that hears about the pinning header after the MITM does.

> A year from now, "sha-256" is going to be ambiguous. Better to say "sha2-256".

Good point, and one that might be made on the SAAG list as well.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 Dec 2011 17:19:19 +0200

> I don't agree that the MITM must control the DNS for this attack to work. As long as the MITM can intercept the TLS handshake, and the client isn't doing OCSP (or the MITM intercepts that too), usi…

The rogue cert works only if it validates. So the attacker will have to have compromised the CA as well. Besides, one could argue that using a certificate without OCSP or checking the CRL is not "error-free", but that would have to be clarified.

> That still doesn't deal with the site that hears about the pinning header after the MITM does.

Agree, but it allows me to make my site safe from rogue pinning attacks now.

---

From: Marsh Ray <[email-masked]>
Date: Mon, 12 Dec 2011 09:52:34 -0600

> Good point, and one that might be made on the SAAG list as well.

It's already somewhat ambiguous now that NIST has
defined SHA[-2]-512/256.

http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4

- Marsh

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Dec 2011 09:06:43 -0800

On Dec 12, 2011, at 7:19 AM, Yoav Nir wrote:

> The rogue cert works only if it validates. So the attacker will have to have compromised the CA as well.

Of course. That is exactly the scenario (and pretty much the only scenario) where key pinning gives the relying party better security.

> Besides, one could argue that using a certificate without OCSP or checking the CRL is not "error-free", but that would have to be clarified.

We disagree. OCSP and CRL checking only bring benefit to the relying party if a certificate is revoked. The key pinning scenario is about a rogue CA issuing a certificate they should not have. There is no revocation issue in that scenario, is there?

> Agree, but it allows me to make my site safe from rogue pinning attacks now.

Sure, but I don't think that is a good enough reason to argue against more information in the spec about this problem, which is what I am requesting.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 Dec 2011 20:55:02 +0200

> http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4

Then that is what it must be called: "sha2-512/256". I think that's a legal string in HTTP headers.

Supposedly this is faster on 64-bit applications. I wonder if that is true in practice. So far, I have seen no implementations of this hash function.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 12 Dec 2011 14:14:12 -0500

> Supposedly this is faster on 64-bit applications. I wonder if that is true in practice. So far, I have seen no implementations of this hash function.

I've done a complete bit-level implementation. It's a straight-forward 
modification to RFC 6234.

     Tony Hansen
     [email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 Dec 2011 21:23:18 +0200

> modification to RFC 6234.

Yeah, me too. But I haven't seen it used in certificates or anything else. I also never measured the performance with either 32- or 64-bit code, and I don't see people rushing to write "HMAC-SHA2-512/256 and its use in IPsec/TLS/SSH/whatever". Last time I checked, it wasn't in OpenSSL either.

---

From: Chris Palmer <[email-masked]>
Date: Mon, 12 Dec 2011 11:38:41 -0800

> 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 s…

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.

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

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…

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

---

From: Marsh Ray <[email-masked]>
Date: Mon, 12 Dec 2011 14:29:52 -0600

On 12/12/2011 12:55 PM, Yoav Nir wrote:
> Supposedly this is faster on 64-bit applications. I wonder if that is true in practice.

SHA-2-512/256 should perform identically to plain SHA-2-512. It's the 
same function only with a different IV.

This site is dedicated to benchmarking hash functions:
http://bench.cr.yp.to/results-hash.html

It doesn't appear to be faster than, say, SHA-1, SHA-2-512 but does not 
appear to be subject to the same attacks either.

> So far, I have seen no implementations of this hash function.

I made one for use at work, but it's only a minor adjustment to the RFC 
6234 SHA-2-512 reference code.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 Dec 2011 22:52:21 +0200

> same function only with a different IV.

Yes, and the claim in the original paper was that SHA2-512 was faster on 64-bit systems than SHA2-256. I haven't verified this.

> 6234 SHA-2-512 reference code.

I did that as well.

---

From: David Illsley <[email-masked]>
Date: Mon, 12 Dec 2011 21:09:28 +0000

> tricking both a registrar and a CA, and paying the latter.

I think the dynamic is changed because at the moment, you have a
registrar which you have a contractual relationship to fall back on
when something goes wrong, and things are likely resolved in a short
period of time. Once the registrar has straightened things out, you've
just got to wait for DNS TTLs to expire and you're good to go.

With pinning, your registrar can still straighten DNS out, but any
visitors who accessed the site in the affected period (hours-tens of
hours at a guess) are pinned to a private key you have no access to.

> they know about the attackers who bought the certs.)

Yeah, it's definitely useful to have more data points, but I'll put my
hands up to being pessimistic about the CA model. The paper trail
might be useful, but a stolen credit card from country A being used in
with a CA in country B when you're in country C might be hard to
really make anything of.

> registrars who work hard to be trustworthy. Pinning makes your choice

We can wish... I'm still hoping we actually get CAs
special-case-checking DV certs for domains which have a publicly
facing EV cert...

> Ok, I'll come up with some text.
Great. Thanks.

> does it happen, how long does it last, how much is the ransom, et c.?

Unfortunately I don't, and I do think pinning does change things
anyway. FWIW, the event that made me think of this was apparently 'for
fun' [1]. Such people might also consider a long-term denial of
service 'fun' :-(
David
[1] http://www.guardian.co.uk/technology/2011/sep/05/turkish-hacker-group-diverts-users