[ysnp]

DNSSEC is one of very few topics where voices I respect on security seem completely opposed (WebPKI depends on DNS vs. DNS security does not matter). Is there any literature that demonstrates deep understanding of both arguments? Why are they (DNSSEC + WebPKI) never considered complimentary?

[ekr____]

You'll have to judge for yourself whether this demonstrates deep understanding of both arguments, but I did try to be evenhanded in these posts:

https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dane/

From my perspective, the challenge with DNSSEC is that it just doesn't have a very good cost/benefit ratio. Once the WebPKI exists, "critical path" use of DNSSEC only offers modest value. Now, obviously, this article is about requiring CAs to check DNSSEC, which is out of the critical path and of some value, but it's not clear to me it's of enough value to get people to actually roll out DNSSEC.

[winstonwinston]

> Why are they (DNSSEC + WebPKI) never considered complimentary?

WebPKI works without DNSSEC, whereas DANE (a more secure WebPKI replacement) depends on a robust DNSSEC deployment.

[indolering]

It can be used alongside WebPKI. And as someone who is worried about other protocols, it sure would be nice if I could setup DNSSEC for my domain and have clients pick up on that automatically.

[TZubiri]

To add a dissenting voice.

I've worked with small businesses and even small technical teams as a DNS consultant specifically.

DNS has only been a source of issues and confusion and not at all related to any requirements, just a form of checkbox implementation.

I do understand it's one of those technologies that are developed due to legitimate requirements, but it flows downstream and people just adopt it without really understanding the simpler solutions or what exactly it's meant to do.

That said if I had ever gotten a bigger client like a TLD registrar or a downstream registrar, then sure I would have had to work with it, but I've only ever had to learn how to uninstall it actually.

[gzread]

Can you explain better the most common problems you run into? I wonder if they can be solved.

[vbezhenar]

My two most common problems:

1. Need to change IP as soon as possible, but DNS record has huge TTL (e.g. 24h).

2. Client ISP DNS does not resolve my domain and it's absolutely not clear how to proceed from here. I don't have connections in huge ISPs, writing stuff to ISP support is as effective as throwing stones in the lake.

Funnily enough, for both cases, /etc/hosts or its Windows equivalent comes to the rescue.

[TZubiri]

1. 24 hours is not common at all for A records, it should be between 5 minutes to 60 minutes.

Perhaps you are thinking of NS records, which would only be changed very infrequently, and both the source and target systems should be up so that there's no loss of availability.

2. Never had that, it's more likely that you did something wrong rather it being an ISP issue.

Feel free to send me an email with specifics, the email is in my profile although in a cryptic format to avoid spam.

[ivanr]

I'll share a couple of thoughts, but do read EKR's blog first:

- Web PKI is inherently insecure and can't be fixed on its own. The root problem is that the CAs we "trust" can issue certificates without technical controls. The best we can do is ask them to be nice and force them provide a degree of (certificate) transparency to enable monitoring. This is still being worked on. Further, certificates are issued without strong owner authentication, which can be subverted (and is subverted). [3]

- The (very, very) big advantage of Web PKI is that it operates online and supports handshake negotiation. As a result, iteration can happen quickly if people are motivated. A few large players can get together and effect a big change (e.g., X25519MLKEM768). DNSSEC was designed for offline operation and lacks negotiation, which means that everyone has to agree before changes can happen. Example: Kipp Hickman created SSL and Web PKI in 3 months, by himself [1]. DNSSEC took years and years.

- DNSSEC could have been fixed, but Web PKI was "good enough" and the remaining problem wasn't sufficiently critical.

- A few big corporations control this space, and they chose Web PKI.

- A humongous amount of resources has been spent on iterating and improving Web PKI in the last 30 years. So many people configuring certificates, breaking stuff, certificates expiring... we've wasted so much of our collective lives. There is a parallel universe in which encryption keys sit in DNS and, in it, no one has to care about certificate rotation.

- DNSSEC can't ever work end-to-end because of DNS ossification. End-user software (e.g., browsers) can't reliably obtain any new DNS resource records, be it DANE or SVCB/HTTPS.

- The one remaining realistic use for DNSSEC is to bootstrap Web PKI and, possibly, secure server-to-server communication. This is happening, now that CAs are required to validate DNSSEC. This one changes finally makes it possible to configure strong cryptographic validation before certificate issuance. [2]

[1] https://www.feistyduck.com/newsletter/issue_131_the_legend_o...

[2] https://www.feistyduck.com/newsletter/issue_126_internet_pki...

[3] https://redsift.com/guides/a-guide-to-high-assurance-certifi...

[assimpleaspossi]

>>do read EKR's blog first

If only I knew who EKR is and where his blog is.

[ivanr]

Ah, sorry, I should have referenced this sibling comment: https://news.ycombinator.com/item?id=47403528

EKR is https://educatedguesswork.org/about/

[bawolff]

> DNSSEC could have been fixed, but Web PKI was "good enough" and the remaining problem wasn't sufficiently critical.

People say this about every failed technology. If you have something that could have been fixed at any point in the last 30 years but somehow never has been, usually i suspect its not actually true.

> Further, certificates are issued without strong owner authentication

I dont think DNSSEC would fix this either and quite frankly i dont think its a super important problem to solve.

[ivanr]

No, DNSSEC can enforce strong cryptographic validation _today_. Here's how:

1. Configure a CAA record that restricts issuance to two CAs that support locking down issuance to specific customer accounts. For example, Let's Encrypt supports RFC 8657; DigiCert has a proprietary mechanism. After this, you can only issue certificates when you properly authenticate against your selected CAs.

2. Use only ACME validation methods that rely on DNS. Avoiding HTTP-01, for example, ensures that a MITM can't intercept that unencrypted network traffic and approve certificates with key material under their control.

3. Deploy DNSSEC. Your DNS is now cryptographically validated, meaning your CAA records can't be spoofed and the validation methods from step 2 can't be spoofed either.

[bawolff]

I didn't dispute this.

[indolering]

Bad arguments and FUD when it was being rolled out. Sysadmins also don't want to touch working infra code, you can see that with AWS lagging on IPv6.

[tptacek]

Who's the most reputable cryptographer you can think of who publicly supports DNSSEC? We'd like to interview them on SCW.

[8organicbits]

Can you not check the RFCs?

[tptacek]

You know the funny thing about this is that I have talked, relatively recently, to one of the very few cryptographers who was an author on a DNSSEC standard, and they wouldn't work for the interview I want to do --- they're not sold enough on DNSSEC anymore.

The broader answer is: the relevant RFCs weren't authored by cryptography engineers. This was a major problem in the "old" IETF, before the cryptographers "took over" tls-wg and CFRG.

At any rate, the reason I asked in that particular place on the thread was that the preceding comment was attempting to draw a line between "sysadmins" who hate DNSSEC and the serious technologists who like it a lot.

[indolering]

You are going to complain that the key sizes are too small despite the guidelines being updated a long time ago. Then you will argue adoption of larger keys sizes is to low. Then you will argue that we should just not sign domain name authority delegation records at all (i.e. DNSSEC) and that we should abandon shoring up authenticated DNS because there is no adoption.

You have any cryptographers that are satisfied with unauthenticated name server checks?

[tptacek]

Yes? Lots of them? But also: you didn't answer my question.

[indolering]

Okay, but after this I have to go back to work.

You got a point: 1k isn't great and of course mainstream cryptographers will advocate for higher. That doesn't change that it's still acceptable within the existing security model nor that better alternatives are available. The cryptographic strength of DNSSEC isn't a limiting factor that fatally dooms the whole project. We have to upgrade the crypto used in large-scale infrastructure all the time!

And yes, uptake of better crypto is poor but I find chicken-and-egg arguments disingenuous when coming from someone who zealously advocates to make it worse. Furthermore, your alternative is no signing of DNS records. Find me a cryptographer who thinks no PKI is a better alternative. I know DJB griped about DNSSEC when proposing DNSCurve, which protects the privacy of the payload but not the intergrity of the payload.

[3eb7988a1663]

Is this a bot gone rogue? Parent asked for a person, and you are shadow-boxing with unasked questions.

[tptacek]

Sorry, but I asked who's the most reputable cryptographer you can think of who publicly supports DNSSEC? I asked because we'd like to interview them on SCW.

[JackSlateur]

False dichotomy

DNSSEC protects email, webpki does not