| ▲ | josephg 6 hours ago |
| Make dns secure and put certs / public keys in dns. Control over dns already gives you the right to get tls certs. It should just be connected directly. We don’t need CAs. |
|
| ▲ | jayd16 19 minutes ago | parent | next [-] |
| So like, the cable company now controls the certs for most consumers? shudders |
|
| ▲ | three14 5 hours ago | parent | prev | next [-] |
| tptacek argues that DNSSEC is too flawed to actually do this: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ |
| |
| ▲ | josephg 4 hours ago | parent | next [-] | | He's right. DNSSEC is a mess, and we should fix that. We should fix that whether or not we delete CAs because CAs rely on DNS to verify that you own your domain. If DNS isn't secure, neither are CAs. In the long run, fixing bugs is almost always better than working around them. DNSSEC is a bug. So are CAs. We can and should fix both. | | |
| ▲ | chimeracoder 3 hours ago | parent [-] | | His argument is that DNSSEC is fundamentally broken, and you can't fix it via incremental improvements. He is not arguing that DNS security cannot or should not be improved; in fact, he explicitly states the exact opposite. | | |
| ▲ | tptacek an hour ago | parent [-] | | I don't have an objection to doing a different DNS security system, and in fact I like DoH a lot. You can do DoH all the way back from authority servers if you like, and that addresses domain validation without boiling the ocean with 1990s cryptography the way DNSSEC tries to do. |
|
| |
| ▲ | GoblinSlayer 3 hours ago | parent | prev | next [-] | | ECDSA was added to DNSSEC 3 years before that blog post in april 2012 (rfc6605). | | |
| ▲ | tptacek an hour ago | parent [-] | | And then for the next 10 years APNIC wrote posts about how actually using ECDSA broke resolvers. It's going to settle into general usability at just about the time cryptographers deprecate ECC entirely! |
| |
| ▲ | ranger_danger 4 hours ago | parent | prev [-] | | I have seen their comments across this site for a very long time. Unfortunately I do not respect or put any stock in what they say, because of how unbelievably rude and dogmatic they are, and always have been. "As a rule, strong feelings about issues do not emerge from deep understanding." | | |
| ▲ | icedchai 4 hours ago | parent [-] | | Fortunately, you can investigate this stuff for yourself and develop your own opinion. IMHO, DNSSEC doesn't actually "secure" much of anything. It can be disabled trivially by anyone operating a resolver. As I mentioned elsewhere, none of the major sites (FAANG) use it. What does that tell you? | | |
| ▲ | ranger_danger 3 hours ago | parent [-] | | Yes I'm not saying DNSSEC is or isn't good. I think a multi-layered approach would be best for redundancy. |
|
|
|
|
| ▲ | shiandow 6 hours ago | parent | prev | next [-] |
| Making DNS secure is not trivial though. In a way that's just moving the problem. |
| |
| ▲ | josephg 4 hours ago | parent | next [-] | | A secure DNS is valuable whether or not we get rid of CAs, since CAs rely on DNS queries to verify domain ownership. And if we have a secure DNS, then CAs are completely redundant. I'd much rather trust a handful of domain registrars than a handful of domain registrars, plus 100 random questionably competent organisations all over the world. Especially when any one of them can generate keys for every domain on the planet. | | |
| ▲ | darkwater 4 hours ago | parent [-] | | It seems a nice thing to have indeed, but domain registrars have already a history to cede control and bend to $GOVERNMENT. We have countries already trying to MiTM all their citizens by mandating CAs injection in every device under their jurisdiction, what would be the defense against this threat in a world where registrars hold the keys to TLS encryption for the web on the TLDs they own as root?
I'm not that expert in this field so I really would like to learn if it's possible. | | |
| ▲ | shiandow 2 hours ago | parent [-] | | Not that it isn't an interesting question but what's preventing them now? You can get a certificate for any domain you control. It is just really obvious if you abuse that power. Which shouldn't really change with DNSSEC I think. |
|
| |
| ▲ | vesinisa 6 hours ago | parent | prev [-] | | Isn't this what DNSSEC solves? | | |
| ▲ | muvlon 5 hours ago | parent | next [-] | | DNSSEC deployment has been anything but trivial. This APNIC post from 2024 estimated that about 1% of DNS queries were being validated via DNSSEC: https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/. That's more than 25 years after the IETF first standardized DNSSEC. | | | |
| ▲ | shiandow 5 hours ago | parent | prev [-] | | It should, though it achieves that goal by a chain of certificates not unlike CAs just tied to DNS. Like I said, it essentially just moves the problem. Which might still be better, if only because it limits the surface area. |
|
|
|
| ▲ | braiamp 6 hours ago | parent | prev | next [-] |
| That still requires trust stores to be distributed to the clients and some clients don't need that baggage on the dns. Also, dns is by default insecure, dnssec is a configuration nightmare |
| |
| ▲ | otabdeveloper4 6 hours ago | parent [-] | | > That still requires trust stores to be distributed to the clients There's no such thing as a "trust store" in practice. To be "trusted" you just need to demonstrate you have control over a DNS TXT record, and we don't need a special "store" or intermediary for that. Certificate authorities are an artifact of a bygone time and an entirely different model of internet infrastructure. | | |
| ▲ | woodruffw 5 hours ago | parent [-] | | The trust store refers to the collection of parties that ultimately verify the signed claim of your control over a domain, which might have taken the form of a DNS TXT challenge (or any other number of challenges). You still need it, because there would otherwise be a basic circularity when determining whether to trust a connection. (Moving the PKI into DNS does not remove it, it just moves it around.) | | |
| ▲ | josephg 4 hours ago | parent [-] | | > (Moving the PKI into DNS does not remove it, it just moves it around.) Better in DNS though. You could have certs mirror the structure of DNS. Install a single root signing key for the top level DNS registry on client devices. Then you can query that to find out the signing keys for .com, .net, .au, etc. And continue from there. One big problem with the CA system is that any CA - even the most incompetent - can sign certificates for any domain. If trust was moved to DNS, there would only be a single organisation that could forge certificates for any given domain. Using 7 as a private key? What a joke. The CAs aren't worthy of trust. We already have to trust the domain name registrars anyway, since CAs query them to figure out if you own a domain before signing a certificate. In total, removing CAs would not only simplify the system. But it would allow scoped signatures. And we'd end up needing to trust far fewer actors to have a secure internet. | | |
| ▲ | itintheory 2 hours ago | parent | next [-] | | > One big problem with the CA system is that any CA - even the most incompetent - can sign certificates for any domain. Is this not what CAA records were intended to solve? It seems like in practice they're only used by CAs to decide if they can sign a cert for a given domain, but it seems like a client could use it to determine if a server cert was from the correct CA. | | |
| ▲ | parasyte 14 minutes ago | parent | next [-] | | CAA records were never intended to be used by clients (Relying Parties), the RFC specifically prohibits them from using the CAA record to determine if the issuer was allowed to have issued the cert. I infer from the wording around there and elsewhere in the RFC that this is mostly because someone could switch issuers but still serve valid certs from the prior issuer, and there's no way an RP would have a historical record of which CAA values were in effect when to be able to determine if the issuance was valid or not. | |
| ▲ | Scott_Helme_ 28 minutes ago | parent | prev [-] | | CAA records are only checked by the CA at the point of issuance, not by the client later. If they did, there are problems to consider: 1. A domain would have to keep the CAA records for a CA in place to keep using the certificates from that CA, but that means continuing to authorise new issuance too. Right now, I can remove the `letsencrypt.org` value to stop them from issuing new certificates for me, but I can keep using any certificates I have until they expire. 2. The client would need to have support for this new DNS RR type. 3. The client would need a secure way to query DNS, which is not widespread. |
| |
| ▲ | woodruffw 3 hours ago | parent | prev [-] | | Why would I trust my domain registrar to maintain PKI? They don’t seem inherently better suited for it, and in various ways are more susceptible to meddling for e.g. ccTLDs. I think the idea that CAs are uniquely incompetent is probably incorrect. |
|
|
|
|
|
| ▲ | asksomeoneelse 6 hours ago | parent | prev [-] |
| But how do you make DNS secure without CAs? |
| |
