I agree with his comments on HPKP. I looked in to adding HPKP headers to a couple of my sites, and figured out how to do it, but I'm nervous about enabling it. It seems far too easy to make a mistake and lock people out of being able to visit your site. The trouble is, if you make a mistake, they're not locked out until you get around to fixing it. They're locked out until the expiry date which you set in the HPKP headers, which could be months away.
Tools to permit you to wipe out your HPKP mistake would be usable by attackers, though. That's hard to solve.
I haven't looked into HPKP much, but it appears it has the ability to be configured in a "report only" mode if name your header "Public-Key-Pins-Report-Only". This will allow you to test your implementation to make sure it's correct before renaming the header to start enforcing.
The idea of a non-enforcing mode for testing purposes also exists in DKIM (though DKIM didn't really catch on much due to servers with proper DKIM configurations getting compromised and sending spam...)
I would say that HSTS is far more dangerous as I don't see a similar "testing" mode available.
edit: It would be a good idea to make sure your max-age setting doesn't exceed the expiration date of your intermediate certificate, so don't go crazy with it. A tool with built-in safeguards to handle most of this configuration would be welcome.
"Tools to permit you to wipe out your HPKP mistake would be usable by attackers, though."
I meant tools to prevent you from making the mistakes in the first place, not for fixing it after the mistake.
The non-enforcing mode doesn't help. When I talk about mistakes, I mean things like losing access to your cert or timing mistakes in rolling the cert. If I roll it out today, it will be fine today. It will probably fail at some point in the future though, and fail hard, unless I follow very strict processes.
HSTS is considerably less dangerous. Once it's set up, it will continue to work without you having to do anything extra. HPKP on the other hand requires you to actively consider when you generate new certs, and when you add extra HPKP headers to your responses, and when you roll the certs etc.
I can change my CA or generate a new key today on a whim, because I don't do HPKP. If I did do HPKP, this would require considerable thought and preparation in advance.
Neither HPKP nor HSTS deal with the issue of a-man-in-the-middle doing a downgrade attack against clients who are visiting a site for the very first time (which can be encouraged through phishing). There are only three ways to deal with this that I can think of:
1) Deprecate insecure HTTP. Literally get all the browsers to agree on a deadline X years out and then drop support for it entirely. HSTS would become irrelevant. I hold little hope of this ever happening, even in a HTTP/2 world. See IPv6
2) Keep increasing the size of the trusted, preloaded list of HTTPS enabled sites shipping with browsers: Neither the implementation nor the process to manage the list scales. It's just crappy all-round.
3) Standardise some SRV records for web protocols in the DNS so browsers can efficiently determine what is supported: Requires DNSSEC to prevent downgrade attacks.
Of these, #3 seems to me to be most practical. With regard to DNSSEC issues I would give these counterpoints:
* DNSSEC could and should be augmented to support ECC, obliterating the concerns with regard to large records and weak RSA key lengths.
* Browsers (or your OS's dnscache process) can cache DNS responses from most of the chain. If the ZSK hasn't been rolled over for a particular domain then I don't see the need to reverify it again on each request. It's not like revocation really works in HTTPS today anyway, so you probably aren't going to bother to check upstream for NSEC records on each request. Or just recheck upstream once a day. I don't really know, but I'm sure these latency issues can be minimized. Googles obsession with latency is how we ended up with the barf that is HTTP/2 rather than something that actually improves websec in the first place.
Another thing I don't often see people mention about HSKP and HSTS, regardless of whether they can be used as "supercookies", is that they create a more-or-less permanent shadow browser history on your machine. This alone is borderline show-stopper afaiac
4) Ask sites to publish via an out-of-band channel their certificate fingerprints in an easy-to-verify manner.
I think the centralised CA model really needs to be replaced, although it will be hard to displace as long as those involved have a financial interest in continuing it.
The problem you're describing has been donned Zooko's triangle. It's unclear whether decentralised solutions to authenticated human-meaningful names can ever scale to something as large as the DNS.
While adoption of DNSCurve would of course be wonderful for privacy online, it cannot be used right now to provide DNS record authentication. The root and TLD nameservers would need to enable support for it, otherwise you'll always be able to MITM the upstream NS record response and redirect all further queries to your own server. Given the politics involved in DNSSEC, and the current anti-crypto climate, I'd say the chances of a fully-chained DNScurve deployment ever happening are about absolute zero.
No, DNSCurve doesn't authenticate DNS records, it only secures integrity and privacy of your requests (and the responses). DNSCurve and DNSSec don't solve the same problem, they're actually complementary.
Whether or not DNSSEC is ever seriously deployed, downgrade attacks against HTTPS will remain viable. It's easy to see one reason why this is true (DNSSEC only protects the DNS lookup and not the HTTP traffic itself), but there are other downgrade attacks as well. Downgrades are hard to protect against.
The objective is to leverage DNSSEC to prevent downgrade attacks. Whether or not you are connecting to a host over HTTP or HTTPS you need to query DNS, which makes it an ideal place to introduce a message to clients to tell them what they should be doing. In an ideal world, a DNSSEC enabled recursive resolver, querying a domain name under a DNSSEC-enabled TLD, should not be fooled to downgrade.
Again: this mitigates (but probably does not decisively solve) one avenue for downgrade attacks. But downgrade attacks against HTTPS would remain possible --- trivial, in fact, without HSTS, which leaves you with the first-contact problem with or without DNSSEC.
So again: what's the point? Compared to HSTS headers, DNSSEC is incredibly expensive.
The point is you can have a record in DNS that says "never use HTTP" that protects clients who haven't yet seen HSTS, and you can use a TLSA-like SRV record to protect clients who haven't yet seen HPKP.
Another thing you're missing is that the CA system almost boils down to the integrity of DNS already, since you can get a CA to issue a basic certificate for a domain simply through weak ownership verification (i.e. if someone controls or MITMs your MX records/responses you're fucked).
Once again: you can foil domain validation with or without DNSSEC by downgrading SMTP.
Why bother with DNSSEC?
You also didn't address my ECC point upthread. Today, APNIC advises DNS administrators not to use the (crappy) P-256 ECDSA DNSSEC supports, because it breaks ~1/3rd of all resolvers. That's for the ECC variant DNSSEC actually "supports".
How exactly would you propose a rollout of Ed25519 (or equivalent) crypto in DNSSEC? Or, where is the flaw in my argument?
Look, I'm not saying DNSSEC is perfect. I don't like it. I just don't see a practical alternative to solving downgrade attacks in the face of such a plethora of crappy Internet protocols.
So what you're saying is DNSSEC isn't finished yet. They need to standardize some equivalent to HSTS that will actually work with browsers on real-world networks, and also some kind of record that prevents SMTP TLS downgrade.
When they do that, maybe I'll re-evaluate DNSSEC. In the meantime: the more people who deploy DNSSEC, the harder it gets to fix the broken crypto, so we should just stop.
The DANE TLSA record already provides the complement to HPKP. The SRV record already provides a complement to HSTS, a convention just needs to be standardized. These HTTP header equivalents are providing a protocol-specific partial solution to a solved problem. This is much like HTTP/2 introduces a protocol specific solution to broader problems with TCP/IP. Nobody seems to care about solving problems thoroughly any more.
The choice of crappy ECC isn't really a technical problem, but a political one. The IETF are wrangling as we speak about the introduction of safe curves in to TLS. djb is lamenting the process.
Btw, I'm all for radical overhaul of the Internet stack, from TCP up, but history tells us radical changes struggle to see adoption. DNSSEC is here and it's easy to deploy (really, it is). It sucks, but it has momentum now and it isn't going away. Killing it without a political push behind a better full-stack solution is just a step backwards.
You're probably correct however in that adopting DNSSEC will reduce the chances of a better alternative making headway, just like adopting HTTP/2 is going to further reduce the chances of SCTP (or something better) adoption ever picking up.
First, I wasn't talking about HPKP, I was talking about HSTS. And TLSA is a complement to HPKP only if "the NSA and DOJ are allowed to override your pin" is an acceptable concession. It of course is not.
Second, there is no DNSSEC equivalent to HSTS. Saying that there could be one is not a very compelling argument. There could be a lot of things.
You're also wrong about the "technical" versus "political" nature of DNSSEC's ECC problem. The technical problem with DNSSEC ECC is that every additional DNSSEC resolver that gets deployed without a modern ECC signature record type makes it harder to roll out that record type in the future. Once again: even the (bad) ECC that DNSSEC already supports breaks fully 1/3rd of the DNSSEC installed base. No part of my argument involves Daniel Bernstein's opinion of the CFRG.
I'm not sure what the analog between HTTP/2 and SCTP is. SCTP is a transport protocol. It's something you'd run HTTP/2 on top of.
In any case: DNSSEC is shitty now, makes the Internet shittier, and actually has the interesting property of getting shittier the more people deploy it. Virtually nobody uses it. If DNSSEC stopped functioning today, no Fortune-500 company would notice. I'm mystified by this notion that we're past some "point of no return" with DNSSEC. We clearly are not.
> Second, there is no DNSSEC equivalent to HSTS. Saying that there could be one is not a very compelling argument. There could be a lot of things.
Wrong, an SRV record for HTTPS already exists[0]. The problem is that the current recommendation is not to publish both "_https._tcp" and "_http._tcp", but to publish only the latter and let the client negotiate HTTPS using redirects and pinning. This recommendation is dumb as it doesn't solve the introduction mitm attack I originally described about 10 posts up. Browser vendors could make a statement on their SRV behaviour and agree to favour https if such a record exists.
> I'm not sure what the analog between HTTP/2 and SCTP is. SCTP is a transport protocol. It's something you'd run HTTP/2 on top of.
HTTP/2s primary achievement is to work around head-of-line blocking in TCP. SCTP already solved that problem. There is now less incentive to push HTTP/1.x streams over SCTP. The parallels are clear with DNSSEC and DNScurve. We have authentication now, it can be done (inefficiently) end-to-end. The added incentive of confidentiality weighed against the cost of a new round of redeployment isn't great. I think DNSSEC has already gone over the tipping point in the circles that ultimately matter.
> In any case: DNSSEC is shitty now, makes the Internet shittier, and actually has the interesting property of getting shittier the more people deploy it.
s~DNSSEC~HTTP/2~
> I'm mystified by this notion that we're past some "point of no return" with DNSSEC. We clearly are not.
I'm not hearing a coherent plan B from you or anyone else to solve these cross-protocol problems. HSTS and HPKP do not solve the problem of shitty CAs, DNSSEC opens to the door to a free alternative that, in the very least, means there are fewer entities we have to trust (hundreds -> a handful). HSTS and HPKP do not solve the introduction problem, DNSSEC adds some hope of helping there. What are your suggestions?
The existence of SRV records does not mean DNSSEC provides the same functionality as HSTS, and you yourself have already explained why. You're moving the goalposts. The argument you're rebutting is "it would be impossible to implement HSTS in DNSSEC". I didn't make that argument. My argument is: even if DNSSEC were widely deployed tomorrow, we would still need HSTS. I'm right about that.
Plan B is "do nothing". That would be a crazy plan if DNSSEC did something to solve the CA problem. It doesn't. It adds a 1483rd CA to the trust model that is heavily influenced by NSA.
Not one person has presented a coherent rebuttal to this point, despite virtually every DNSSEC proponent starting their response to my criticism "DNSSEC is not a government controlled PKI". Their arguments are all uniformly: "DNSSEC is not a government controlled PKI, except for the places like .COM and .IO, where that's exactly what it is".
> My argument is: even if DNSSEC were widely deployed tomorrow, we would still need HSTS. I'm right about that.
You are, but my argument is, even if HSTS reaches 100% adoption, we still need something else.
> That would be a crazy plan if DNSSEC did something to solve the CA problem. It doesn't. It adds a 1483rd CA to the trust model that is heavily influenced by NSA.
It's naïve to think the NSA don't already have keys to a whole bunch of trusted CAs. The NSA are irrelevant to this discussion. When it comes to rogue CAs or system compromise however, having 1 CA to trust is better than X hundred. And, iirc, current browsers rightly ignore HSTS/HPKP for self-signed certs without an additional trust anchor (like DNS pinning).
Around and around we go, avoiding the key point. It's all about who you want to trust.
This debate plays out like a go joseki. Predictably, we've reached the part where the pro-DNSSEC side says, in effect, "NSA controls the Internet anyways, so it doesn't matter if we give them more control".
Sorry, I have a problem with the deployment of entire new Internet cryptosystems that grant NSA huge privileges by design. A decade of crypto engineering may have instilled an irrational bias against broken, compromised cryptosystems. To me: crypto should be something that makes NSA's job harder, not easier.
I'm on your side, really. It's only my cynicism that puts me on the 'fuck it, if we're going to have DNSSEC let us at least leverage it well' side of the fence. That's exactly the same attitude as HPKP and HSTS in HTTP: 'Well HTTP sucks, let's see what we can do'.
NSA certainly is a resourceful adversary. But may I point out what Thomas wrote in his FAQ about this?
”If over the next 5 years nothing more is done to shore up Internet security than is already being done, targeted CA-based attacks will become much riskier for NSA and GCHQ because of key pinning. To man-in-the-middle an HTTPS connection, NSA will need to know that the browser they’re targeting hasn’t already cached the correct key fingerprint for the server. If it has, the browser will scream bloody murder and, hopefully, report back to Google or the EFF about the discrepancy. People watching those logs will quickly discover which CAs are signing bogus certificates, and compromised CAs will be evicted from browsers. NSA and GCHQ will have to risk burning an entire CA every time they launch this attack. If we do nothing new at a protocol level, every Chrome and Firefox installation on the Internet will become part of a global anti-surveillance surveillance system.”
27 comments
[ 11.8 ms ] story [ 62.2 ms ] threadWe lack the proper tools to make this safe.
I haven't looked into HPKP much, but it appears it has the ability to be configured in a "report only" mode if name your header "Public-Key-Pins-Report-Only". This will allow you to test your implementation to make sure it's correct before renaming the header to start enforcing.
The idea of a non-enforcing mode for testing purposes also exists in DKIM (though DKIM didn't really catch on much due to servers with proper DKIM configurations getting compromised and sending spam...)
I would say that HSTS is far more dangerous as I don't see a similar "testing" mode available.
edit: It would be a good idea to make sure your max-age setting doesn't exceed the expiration date of your intermediate certificate, so don't go crazy with it. A tool with built-in safeguards to handle most of this configuration would be welcome.
I meant tools to prevent you from making the mistakes in the first place, not for fixing it after the mistake.
The non-enforcing mode doesn't help. When I talk about mistakes, I mean things like losing access to your cert or timing mistakes in rolling the cert. If I roll it out today, it will be fine today. It will probably fail at some point in the future though, and fail hard, unless I follow very strict processes.
HSTS is considerably less dangerous. Once it's set up, it will continue to work without you having to do anything extra. HPKP on the other hand requires you to actively consider when you generate new certs, and when you add extra HPKP headers to your responses, and when you roll the certs etc.
I can change my CA or generate a new key today on a whim, because I don't do HPKP. If I did do HPKP, this would require considerable thought and preparation in advance.
1) Deprecate insecure HTTP. Literally get all the browsers to agree on a deadline X years out and then drop support for it entirely. HSTS would become irrelevant. I hold little hope of this ever happening, even in a HTTP/2 world. See IPv6
2) Keep increasing the size of the trusted, preloaded list of HTTPS enabled sites shipping with browsers: Neither the implementation nor the process to manage the list scales. It's just crappy all-round.
3) Standardise some SRV records for web protocols in the DNS so browsers can efficiently determine what is supported: Requires DNSSEC to prevent downgrade attacks.
Of these, #3 seems to me to be most practical. With regard to DNSSEC issues I would give these counterpoints:
* DNSSEC could and should be augmented to support ECC, obliterating the concerns with regard to large records and weak RSA key lengths.
* Browsers (or your OS's dnscache process) can cache DNS responses from most of the chain. If the ZSK hasn't been rolled over for a particular domain then I don't see the need to reverify it again on each request. It's not like revocation really works in HTTPS today anyway, so you probably aren't going to bother to check upstream for NSEC records on each request. Or just recheck upstream once a day. I don't really know, but I'm sure these latency issues can be minimized. Googles obsession with latency is how we ended up with the barf that is HTTP/2 rather than something that actually improves websec in the first place.
Another thing I don't often see people mention about HSKP and HSTS, regardless of whether they can be used as "supercookies", is that they create a more-or-less permanent shadow browser history on your machine. This alone is borderline show-stopper afaiac
I think the centralised CA model really needs to be replaced, although it will be hard to displace as long as those involved have a financial interest in continuing it.
https://en.wikipedia.org/wiki/Zooko%27s_triangle
Since DNSSEC can't decisively fix HTTPS downgrade, why bother deploying it?
I addressed your ECC point in the followup to my post:
http://sockpuppet.org/stuff/dnssec-qa.html
Adam Langley seems to agree; he said "it won't happen within 10 years".
So again: what's the point? Compared to HSTS headers, DNSSEC is incredibly expensive.
Another thing you're missing is that the CA system almost boils down to the integrity of DNS already, since you can get a CA to issue a basic certificate for a domain simply through weak ownership verification (i.e. if someone controls or MITMs your MX records/responses you're fucked).
Why bother with DNSSEC?
You also didn't address my ECC point upthread. Today, APNIC advises DNS administrators not to use the (crappy) P-256 ECDSA DNSSEC supports, because it breaks ~1/3rd of all resolvers. That's for the ECC variant DNSSEC actually "supports".
How exactly would you propose a rollout of Ed25519 (or equivalent) crypto in DNSSEC? Or, where is the flaw in my argument?
Look, I'm not saying DNSSEC is perfect. I don't like it. I just don't see a practical alternative to solving downgrade attacks in the face of such a plethora of crappy Internet protocols.
When they do that, maybe I'll re-evaluate DNSSEC. In the meantime: the more people who deploy DNSSEC, the harder it gets to fix the broken crypto, so we should just stop.
The choice of crappy ECC isn't really a technical problem, but a political one. The IETF are wrangling as we speak about the introduction of safe curves in to TLS. djb is lamenting the process.
Btw, I'm all for radical overhaul of the Internet stack, from TCP up, but history tells us radical changes struggle to see adoption. DNSSEC is here and it's easy to deploy (really, it is). It sucks, but it has momentum now and it isn't going away. Killing it without a political push behind a better full-stack solution is just a step backwards.
You're probably correct however in that adopting DNSSEC will reduce the chances of a better alternative making headway, just like adopting HTTP/2 is going to further reduce the chances of SCTP (or something better) adoption ever picking up.
Second, there is no DNSSEC equivalent to HSTS. Saying that there could be one is not a very compelling argument. There could be a lot of things.
You're also wrong about the "technical" versus "political" nature of DNSSEC's ECC problem. The technical problem with DNSSEC ECC is that every additional DNSSEC resolver that gets deployed without a modern ECC signature record type makes it harder to roll out that record type in the future. Once again: even the (bad) ECC that DNSSEC already supports breaks fully 1/3rd of the DNSSEC installed base. No part of my argument involves Daniel Bernstein's opinion of the CFRG.
I'm not sure what the analog between HTTP/2 and SCTP is. SCTP is a transport protocol. It's something you'd run HTTP/2 on top of.
In any case: DNSSEC is shitty now, makes the Internet shittier, and actually has the interesting property of getting shittier the more people deploy it. Virtually nobody uses it. If DNSSEC stopped functioning today, no Fortune-500 company would notice. I'm mystified by this notion that we're past some "point of no return" with DNSSEC. We clearly are not.
Wrong, an SRV record for HTTPS already exists[0]. The problem is that the current recommendation is not to publish both "_https._tcp" and "_http._tcp", but to publish only the latter and let the client negotiate HTTPS using redirects and pinning. This recommendation is dumb as it doesn't solve the introduction mitm attack I originally described about 10 posts up. Browser vendors could make a statement on their SRV behaviour and agree to favour https if such a record exists.
> I'm not sure what the analog between HTTP/2 and SCTP is. SCTP is a transport protocol. It's something you'd run HTTP/2 on top of.
HTTP/2s primary achievement is to work around head-of-line blocking in TCP. SCTP already solved that problem. There is now less incentive to push HTTP/1.x streams over SCTP. The parallels are clear with DNSSEC and DNScurve. We have authentication now, it can be done (inefficiently) end-to-end. The added incentive of confidentiality weighed against the cost of a new round of redeployment isn't great. I think DNSSEC has already gone over the tipping point in the circles that ultimately matter.
> In any case: DNSSEC is shitty now, makes the Internet shittier, and actually has the interesting property of getting shittier the more people deploy it.
s~DNSSEC~HTTP/2~
> I'm mystified by this notion that we're past some "point of no return" with DNSSEC. We clearly are not.
I'm not hearing a coherent plan B from you or anyone else to solve these cross-protocol problems. HSTS and HPKP do not solve the problem of shitty CAs, DNSSEC opens to the door to a free alternative that, in the very least, means there are fewer entities we have to trust (hundreds -> a handful). HSTS and HPKP do not solve the introduction problem, DNSSEC adds some hope of helping there. What are your suggestions?
[0] http://dns-sd.org/ServiceTypes.html
Plan B is "do nothing". That would be a crazy plan if DNSSEC did something to solve the CA problem. It doesn't. It adds a 1483rd CA to the trust model that is heavily influenced by NSA.
Not one person has presented a coherent rebuttal to this point, despite virtually every DNSSEC proponent starting their response to my criticism "DNSSEC is not a government controlled PKI". Their arguments are all uniformly: "DNSSEC is not a government controlled PKI, except for the places like .COM and .IO, where that's exactly what it is".
You are, but my argument is, even if HSTS reaches 100% adoption, we still need something else.
> That would be a crazy plan if DNSSEC did something to solve the CA problem. It doesn't. It adds a 1483rd CA to the trust model that is heavily influenced by NSA.
It's naïve to think the NSA don't already have keys to a whole bunch of trusted CAs. The NSA are irrelevant to this discussion. When it comes to rogue CAs or system compromise however, having 1 CA to trust is better than X hundred. And, iirc, current browsers rightly ignore HSTS/HPKP for self-signed certs without an additional trust anchor (like DNS pinning).
Around and around we go, avoiding the key point. It's all about who you want to trust.
Sorry, I have a problem with the deployment of entire new Internet cryptosystems that grant NSA huge privileges by design. A decade of crypto engineering may have instilled an irrational bias against broken, compromised cryptosystems. To me: crypto should be something that makes NSA's job harder, not easier.
We may be at an impasse.
NSA certainly is a resourceful adversary. But may I point out what Thomas wrote in his FAQ about this?
”If over the next 5 years nothing more is done to shore up Internet security than is already being done, targeted CA-based attacks will become much riskier for NSA and GCHQ because of key pinning. To man-in-the-middle an HTTPS connection, NSA will need to know that the browser they’re targeting hasn’t already cached the correct key fingerprint for the server. If it has, the browser will scream bloody murder and, hopefully, report back to Google or the EFF about the discrepancy. People watching those logs will quickly discover which CAs are signing bogus certificates, and compromised CAs will be evicted from browsers. NSA and GCHQ will have to risk burning an entire CA every time they launch this attack. If we do nothing new at a protocol level, every Chrome and Firefox installation on the Internet will become part of a global anti-surveillance surveillance system.”
http://sockpuppet.org/stuff/dnssec-qa.html