Live data from Hacker News

First-ever DNSSEC root key rollover

redhat.com

71–75 of 75 posts

Re: First-ever DNSSEC root key rollover

#71

Earlier quoted context omitted.

Were the domains using TLS?

Does it matter? If the attackers can redirect the domain names to their own IP addresses then they can obtain DV certificates for those domains. The security of TLS depends on secure domain name resolution.

1. Virtually nobody signs zones today, so this is a moot point.

2. Not all DV-issuing CAs reliably verify DNSSEC, so it's even mooter.

3. Even if everyone signed their zones today, the Five Eyes intelligence agencies (NSA, ASD, GCHQ, GCSB, and CSE) have de facto (and, in some cases, de jure) control over the most important TLD zones.

4. The Web PKI already has countermeasures in place to detect misissuances, and those countermeasures have already resulted in the deaths of several of the largest CAs; there is ample evidence that current Web PKI surveillance is up to the task.

5. Even with secure DNS resolution, DV cert verification processes don't have a secure channel, and remain vulnerable to traffic interception attacks; for instance, even with DNSSEC, BGP attacks can straightforwardly trick CAs.

6. There are countermeasures to DNS spoofing that are simpler to deploy than DNSSEC, especially in the limited settings needed for DV cert verification; for instance: multi-perspective DNS and DNS over HTTPS.

7. There is already work happening to link CAs directly to registrars using RDAP to bypass DNS entirely for domain validation. In addition to being more reliable than DNSSEC, RDAP is also drastically simpler to deploy, and doesn't require anyone to sign their zones.

DV certificate issuance and SMTP-TLS were the last two mainstream drivers for DNSSEC adoption. The Web PKI has worked around the problem, and, with SMTP-STS (a standard whose specific, stated rationale is to work around DNSSEC), so have the largest email providers.

In fact: nothing depends on secure domain resolution, all meaningful Internet protocol security work over the last two decades has been premised on DNS being insecure, and DNSSEC is done. Stick a fork in it.

Re: First-ever DNSSEC root key rollover

#72
post #25
post #18

This was supposed to have happened a year ago (I think almost to the day?), but was aborted roughly a week before because nobody was confident the system would survive. Apparently it did this time! An unfortunate attribute of DNSSEC: nothing depends on it, to the extent that you could almost certainly post the root private keys on Pastebin and not cause a single mainstream site a problem. At the same time, if you scr…

Big five tech giants aren't playing, and I don't know any bank domains, but it's not hard to find names: cloudflare.com verisign.com comcast.net *.gov Every time dnssec shows up there's a tptacek comment crapping on the medium. are you using google alerts or something? what were your consulting fees for this service?

This comment breaks the site guidelines and your one downthread is even worse. You can't attack another user like that on HN, and we ban accounts that do it. Please review https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here, regardless of how wrong you think someone is about something.

Re: First-ever DNSSEC root key rollover

#73
post #71

Earlier quoted context omitted.

Does it matter? If the attackers can redirect the domain names to their own IP addresses then they can obtain DV certificates for those domains. The security of TLS depends on secure domain name resolution.

1. Virtually nobody signs zones today, so this is a moot point. 2. Not all DV-issuing CAs reliably verify DNSSEC, so it's even mooter. 3. Even if everyone signed their zones today, the Five Eyes intelligence agencies (NSA, ASD, GCHQ, GCSB, and CSE) have de facto (and, in some cases, de jure ) control over the most important TLD zones. 4. The Web PKI already has countermeasures in place to detect misissuances, and tho…

> Even with secure DNS resolution, DV cert verification processes don't have a secure channel, and remain vulnerable to traffic interception attacks; for instance, even with DNSSEC, BGP attacks can straightforwardly trick CAs.

3.2.2.4.7 just does DNS, so DNSSEC can secure it regardless of "traffic interception" or other shenanigans.

Tightening up the Web PKI happens gradually. In 2017 we required the Ten Blessed Methods (3.2.2.4.x) to replace a previous free-for-all, and then we've whittled away those ten so that today there are only eight left, of which one is secured by DNSSEC and several are out-of-band, so shenanigans on the Internet won't help you there. I won't be surprised if it's six by late next year.

Re: First-ever DNSSEC root key rollover

#74
post #53
post #32

Earlier quoted context omitted.

But why do you want it? DNSSEC and TLS cover much of the same use cases - except DNSSEC is worse. IIRC, it uses 1024bit RSA keys - which are large, and yet not particularly strong. It gives you very little flexibility - if you own example.com, you have to trust the root key and Verisign and whatever governments have authority over them and the only way out is to change to a different domain name. And what seemed like…

If your attack model includes Verisign or a government modifying your DNS zone, then that will allow them to obtain a DV certificate as well. By and large, TLS security depends on the connectness of DNS. Though you could try your luck with HTTP public key pinning (HPKP). I fully agree that 1024 bit keys are silly.

HPKP is about to only be usable on Firefox since IE/Edge never supported it and Chrome has deprecated and is about to remove it.

Re: First-ever DNSSEC root key rollover

#75
post #32
post #17

But when will it be supported in Route53?

But why do you want it? DNSSEC and TLS cover much of the same use cases - except DNSSEC is worse. IIRC, it uses 1024bit RSA keys - which are large, and yet not particularly strong. It gives you very little flexibility - if you own example.com, you have to trust the root key and Verisign and whatever governments have authority over them and the only way out is to change to a different domain name. And what seemed like…

I want it because above my pay grade has decided, for "reasons" they want it. These reasons, that I may or may not agree with, are valid and reasonable. It's my role to implement. We have loads of other services in AWS but because of our DNSSEC requirement we can't use that one. It's a minor technical headache the Ops team has to deal with -- 99% in AWS except this other critical piece.
Post reply on HN