Hacker News Reader

Comment by pfg | Hacker News Reader

In the modern Web PKI, it seems to me that the only thing DNSSEC is good for is mitigating BGP hijacking and similar attacks (in combination with CAA and either some contractual agreement with your CA or the ACME CAA extension).

That's an important issue to solve, but you wouldn't need anything with the complexity and baggage of DNSSEC to do that.

DNSSEC, to a degree, stands in the way of a better solution. And while I have no problem with people using DNSSEC as an additional layer of defense as such, I feel like there's a risk that people will use it as the only layer of defense if it becomes a success, effectively blindly trusting DNS.

View on HN

Wait, how would DNSSEC possibly mitigate BGP hijacking?

I heard this last time there was a publicized BGP-hijacking incident and it made no sense to me then and still doesn't now. Attackers who control BGP control IP addresses themselves, the things DNS records point to. They don't even need to touch the DNS to intercept traffic.

The magic sauce would be CAA. This is under the assumption that all publicly trusted CAs respect CAA and have no bypass bugs (CAs probably aren't ... too far off target) and that they properly validate DNSSEC (good luck with that, I don't think there's even consensus on what the Baseline Requirements consider compliant).

Anyway, in this mostly hypothetical world where all of that works as intended, you could use a CAA record with just one or two CAs with which you have some kind of contractual relationship requiring out-of-band verification. Alternatively (and, IMO, preferable, since the controls are technical), you can use the ACME CAA extension[1] to lock down the validation methods to just DNS-based ones, or bind the the whole validation flow to a key. Let's Encrypt is working on this currently[2].

[1]: https://tools.ietf.org/html/draft-ietf-acme-caa-05#section-4

[2]: https://community.letsencrypt.org/t/acme-caa-validationmetho...

My understanding is (a) the current interpretation of the BR's does not require DNSSEC, and that (b) validation of DNSSEC among CAs is not the norm; CAs have disabled it because it proved unreliable.

It's certainly not an interpretation I'd punish a CA for, the language in section 3.2.2.8 is rather ambiguous.

Let's Encrypt is running a fail-close setup for DNSSEC, so I wouldn't quite say it's too unreliable in this particular context. Still, it's quite clear that DNSSEC's complexity is getting in the way of things here. A solution just for this specific use-case would be much simpler overall, and I'm not buying into any of the other benefits DNSSEC claims to bring, so I'd rather just see it die.

> DNSSEC, to a degree, stands in the way of a better solution.

When no such "better solution" exists this is wishful thinking, we might make the same argument for any number of core systems and protocols.

In particular you've offered no evidence whatsoever that a system could be developed (much less _has_ been developed and thus offers a viable alternative) which avoids "blindly" trusting authoritative answers from name owners about their names...

Historically the rationale for why we can't do DNSSEC on clients is that it won't work because of middleboxes. The present topic is of course about deliberately altering clients so as to bypass middleboxes and so actually this is a world where DNSSEC works much _better_ than ever before.

This doesn't make any sense. First, it's plainly obvious that we could design replacements for essentially any protocol. Second, the fundamental design problems that would motivate and be corrected in a new DNSSEC are obvious:

* Offline signers was a mistake, since virtually all leaf authority servers are online signers due to the NSEC debacle.

* A protocol with less than 20% saturation in 2018 that expects to be deployed would be based on a modern signature scheme, not RSA.

Just altering those two elements of the design would allow for a radically improved protocol.

I'm 41 years old. The DNSSEC design being promoted right now was started when I was still in high school, during the phlogiston era of cryptographic protocol design. It is lunacy to believe that it is the best thing we can come up with.

Reply on news.ycombinator.com