Hacker News Reader

I get it, it’s cool to shit on DNSSEC. But let’s talk about defense in depth. The way you solve account hijacking is two fold. First: authenticate records. Second: don’t trust registrars to produce the contents of records. Reduce registrars to a simple ledger indicating which key to trust for a domain along with the length of the lease. Make people take care of their keys. If a registrar does offer to sign records on an owner’s behalf, maybe don’t use it for security critical services like email.

I don’t think the desire to authenticate data coming from the internet’s global public key-value store is ludicrous.

How does (2) solve the problem? Why wouldn't the attacker just replace the key with their own?

To do so they would have to pop the registrar's account/service, not an individual domain owner's.

How does the registrar know which key to trust? There must be some way for the domain owner to indicate their key, and to replace it if they lose it; essentially, a website where you login and upload your key, much like you currently login and configure your records.

Every useless security product ever pitched has justified its existence with "defense in depth".

> Every useless security product ever pitched has justified its existence with "defense in depth".

Even if this is true it is also shallow, misleading and IMO more of a master suppression technique[0]: even if we accept it as true it doesn't mean the opposite is true (i.e. that everything that is marketed as "defence in depth" is a useless security product.

[0]: https://en.wikipedia.org/wiki/Master_suppression_techniques

You're rebutting an argument that I didn't make. What I said was that "defense in depth" is a weak argument. I didn't say that any solution that invokes "defense in depth" is bad. DNSSEC is bad on its own merits.

Let's just secure the perimeter and live in a world of VPNs and negligently open hosts. I'm not strictly arguing that DNSSEC is a good thing. But I do think it makes sense to authenticate data flowing across general networks, no? You're saying the problem isn't a problem because part of the solution is stupid today. I guess it's job security for security professionals to have insecure things floating around that need additional security? At least some people want to solve the problem. The internet as it exists today being engineered around insecure DNS is not a feature. Name one other scenario where there's a preference for no security.

People used to say the same thing about the boot process. Now we have secure boot. Maybe that's just stupid too but I feel a lot better knowing that my hardware is booting verified images than whatever happens to be sitting at some address in unprotected memory (as long as I remain the owner of the key).

Let's not have negligently open hosts or DNSSEC. In fact: that's pretty much what competent operators do today. See! No changes needed.

> Let it fail all the way away.

Given that just about everyone here recognizes the bad faith shown by ICANN on this issue, it seems to be an act of desperation on their part. Why? They've invested a lot into DNSSEC and are emotionally wrapped up in it, despite better alternatives. And maybe more importantly, if you consider DNS an asset, then its value rises by stuffing more "value" into it such as key escrow. Therefore DNS's principal holders (ICANN, TLDs) would see their asset depreciate if DNSSEC fizzles and dies.

RDAP sounds great, that'll essentially do what I think DNSSEC is for now. I'm going to look into that more.

For it to really help though, DV using DNS needs to stop working. That's going to take a while, but I guess the same goes for convincing all Registrars to use DNSSEC. In that sense, it seems like IANA should be pushing for RDAP.

Certificate Transparency logs are kind of orthogonal to DNSSEC and DV though. The main value in Certificate logs is forcing CAs to act honestly. CA's not getting accurate DNS records is not completely something the CA's can prevent, because they can't authenticate DNS records. Though certainly, they can do their best by using multi-perspective look-ups and other things.

I still think it's scary that registrars have ultimate power over issuance. They seem like the next weak link after CT logs are widespread enough to defend against rogue CAs. Luckily, it is harder for a registrar you don't use to claim your domain, so it is easier to defend by choosing a registrar you trust.

RDAP is just a JSON based version of whois and the registrars and registries will produce the data from the their records the same way they do now.

If an attacker removes DNSSEC at the same time as making name server changes there is no way to detect a difference from a legitimate change.

RDAP is an extensible and uniform channel directly to registrars. CA/B forum has already discussed using it as a DV proof.

An other view of the history of Internet network security is largely the history of plain text protocols getting encryption and authentication. As much as some is arguing against the introduction of authentication in DNS, there are a similar push in the opposite direction where people instead want to add encryption.

For now most of that discussion is the two dominating methods to get encryption and authentication between the user and recursive resolver, but there are plenty of good reasons why we want the same standard of security between recursive resolver and authoritative resolver.

> An other view of the history of Internet network security is largely the history of plain text protocols getting encryption and authentication.

Telnet was replaced by ssh, but they're both connection-oriented protocols that create a session between two endpoints. The same is true of the transition from X to X-over-TLS for the various values of X.

DNS isn't really a connection-oriented protocol to begin with and DNSSEC isn't really a protocol at all, it's a collection of DNS records for use in signature verification. Moreover, it's not encryption, only signatures. It doesn't provide privacy protection. The DNS equivalent to the transition to ssh or TLS would be something like DNSCurve, which is a transport protocol and does encrypt the data.

Note that we actually got what DNSCurve was offering, in the form of DoTLS and DoH.

Not entirely. The promise of DNSCurve is that the authoritative servers can use it too. If they do, it can secure the queries between the recursive resolvers and the authoritative servers as well, and inherently provides secure delegation between administrative boundaries when the parent and child domain both use it.

DNS over TLS/HTTPS typically only secures the link between the client and the resolver, and does so at the complexity cost of bringing in all of TLS and its problematic CA system, and HTTP on top of that for DoH. And the proposals to make it work to the authoritative nameservers have it using DANE (i.e. DNSSEC).

There is no reason that the authorative DNS Server couldn't use DNS over TLS/HTTPS as well.

TLS could be used in much the same way that a mining truck could be used by a letter courier service. You can, doesn't mean you should.

With DNSCurve, when you have a delegation from one authoritative server to another, the parent domain provides the name of the child domain's nameserver, which encodes its public key. Then you use the public key to communicate with the child nameserver. The key distribution is part of the protocol.

To use TLS, you would either have to rely on the CA system with all its problems (any malicious CA can forge any name and many are operated by potential adversaries), or DANE, and then we're creating a dependency on DNSSEC rather than replacing it. Worse, you have to choose one or the other for everyone or else support both as options and have the worst of both worlds in combined complexity and lowest common denominator security.

The overhead of DoT/DoH is also worse in the recursive case. Between the client and the recursive DNS server, creating a TLS session is expensive but at least then you can keep it active and use it for all your queries. In the recursive case the queries go to/from many different authoritative servers, each with low probability of reusing the connection such that keeping it active long is counterproductive. So you're moving from a single UDP request and reply to a full TCP handshake + TLS handshake for as little as a single query. This adds both computation and latency.

Moreover, the one redeeming quality of DNS over TLS/HTTPS is avoiding interference by middleboxes, which exists almost entirely in the context of client devices on restrictive networks rather than the links between recursive and authoritative DNS servers.

DNS is just as much a connection-oriented protocol as http. It just happens that DNS uses caches a bit more than the web because of "reasons", so we got all those caches called recursive resolves being the default.

An early argument against HTTPS was that you could not use web proxies any more. Today we don't normally talk about that, in part because the caching was moved away from the middle and into the server end.

The discussion around how useful DNSSEC misses the point that what history has shown is that authentication without encryption is like encryption without authentication. We need both and preferable done yesterday.

>DNS is just as much a connection-oriented protocol as http

DNS (UDP) is a strictly connection-less protocol. There is no state, there is no transport guarantees, its total fire-and-forget.

https://en.wikipedia.org/wiki/Connectionless_communication

DNS runs just fine over TCP.