Hacker News Reader

Comment by rocqua | Hacker News Reader

As long as domain validation is the standard for getting certs, the security of the DNS system will be part of the security of DNS.

At the moment, DNSSEC is the only off-the-shelf authenticated DNS system. We need that authentication between the DNS servers and the Certificate Authorities. DNSSEC between the DNS server and hosts doesn't matter much. There are other ways to MitM, and insecure fallback is inevitable.

In the end, the DNS system is what we use for identity management, so it should be authenticated. As the recent attacks have shown, the actual administration of the DNS servers (Registrars) also needs to be secured. That is not DNSSEC's role.

But in our current system, if a registrar is compromised, the system is compromised anyway. I'd love to hear an idea that obviates the need to trust Registrars. Without such an option, I don't think 'this doesn't defend against DNS account hijacking' counts, because nothing defends against DNS account hijacking.

Once someone has that account, you are fucked. HPKP is essentially the only thing that could save you, and that has (rightly) been deprecated.

View on HN

There is in fact very little evidence that we "need" the authentication provided by DNSSEC. Here we have an illustration of a phenomenon we've seen repeatedly: an attack for which DNSSEC has absolutely no utility, used deceptively as an argument for the necessity of DNSSEC. The same was true of claims that DNSSEC was a necessary response to BGP hijacking a few months ago.

If there were actual routine attacks that DNSSEC was seriously defending against, you don't think its advocates would be sounding their trumpets about them incessantly? Occam's Razor argues emphatically that the attacks DNSSEC deals with aren't occurring.

Meanwhile: if the reason we need DNS security is for certificate issuance, DNSSEC is a stupid way to get that. We can and will create a secure channel directly between CAs and registrars (one such system is RDAP, the upcoming replacement for WHOIS). We also have systems in place that have demonstrably defeated misissuance, most notably certificate transparency, which does not in any way depend on DNSSEC. CAs can and will do multi-perspective DNS lookups, which are valuable (though imperfect) even against the BGP attacks that completely bypass DNSSEC.

The history of Internet network security is largely the history of higher-layer systems routing around the insecurity of DNS; an insecure DNS is practically the premise of Internet security. And throughout that entire history, going all the way back to when I was in high school in the early-mid 1990s, DNSSEC advocates have been trying to foist this boondoggle of a protocol onto us. It was annoying when it was just a bad cryptosystem that was impossible to configure. But now it's a key escrow system as well. Fuck that. DNSSEC is still failing. Let it fail all the way away.

> 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.

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.

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.

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.

Your reasoning is of the form, "We need something. This is something. Therefore we need this."

No, actually we don't. We don't need this unless we can demonstrate that it makes things better in the real world, with real problems that people really encounter.

The problem isn't simply that it fails to protect against DNS account hijacking. The problem is that it makes the common problem of DNS account hijacking even worse than it is now. Which means that it makes an existing problem bigger than it is now.

Yes, it also solves another problem. But now we have to look at it as a tradeoff between two problems, decide which is worse, and decide accordingly. Every security professional and network admin that I trust finds the tradeoff obvious, and not in DNSSEC's favor.

To give an example of how things get better in the real world: Let's Encrypt won't issue a certificate if your DNSSEC records are invalid.

Sadly, if you can spoof DNS replies, you can probably strip the DNSSEC records. You need fail-closed systems for security, but fail-closed systems are not user friendly, and thus won't be accepted.

> if you can spoof DNS replies, you can probably strip the DNSSEC records

You can't. DNSSEC has explicit protections against that.

Those don't work if you claim to be a non DNSSEC compliant resolver. Should clients really fail closed when faced with a non DNSSEC resolver they got from e.g. the starbucks WiFi DHCP? And if they should, do you really think they will? Because users will complain loudly.

Clients, no. Certificate Authorities like Let's Encrypt, yes. (And in fact, they already do behave that way.)

> Your reasoning is of the form, "We need something. This is something. Therefore we need this."

Pretty much, though I would rephrase it to:

X seems useful, Y is the only realistic way to get X soon, so Y has a valid use case.

Notably, tptaeck mentioned RDAP which might make "Y is the only realistic way to get X soon" wrong.

To secure against these attacks, registrars and dns hosting providers need to improve the management of the zone. Things like allowing NS, DNSKEY, and DS record updates to be authorized separately from other record management. To limit the general updates to standard DNS records.

This doesn’t fix the problem of course as access can still be gained to the master admin account if it’s credentials have been compromised, which is true about nearly every service on the internet. DNS is no different, except of course that it’s critical to serving traffic to a site.

I agree with the GP in that ICANN is being dishonest in encouraging DNSSEC as a response to hijacked accounts. What they should be pushing for is better security practices, like 2FA, by the registrars and more authorization limited options for limiting the exposure of an account to common updates versus less common more critical ones.

Isn't dnscurve a better alternative? Dnscrypt? Etc

dnscurve and dnscrypt handle a different use case than DNSSEC. DNSSEC allows for the records in a DNS zone to be verified via signatures, also stored in the zone, RRSIGs, against keys also registered in the zone, DNSKEYs, which are pinned to the zone along with the NS records in the parent zone via a record called a DS record.

dnscurve and dnscrypt are in the same space as DNS-over-HTTPS, DoH, and DNS-over-TLS, DoT. What they do is authenticate the dns server (resolver) and also encrypt the channel giving you privacy.

DNSSEC == authenticated records. dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions.

And, of course, one of these is a real problem and is seeing widespread deployment and has a bright future, and the other isn't and has been failing since approximately 1994.

> DNSSEC == authenticated records. dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions.

But notice that authenticated resolutions get you authenticated records provided you do them all the way to the root. The root servers on down could support DNSCurve or similar and you could operate recursively using it, or have your trusted recursive resolver do so as you in turn reach it using the same mechanism.

Meanwhile that wouldn't break the cases where you want your DNS server to modify records, e.g. for blocking tracking domains.

Authenticated resolution does not give you authenticated records. You cannot verify that the response between root and your resolver wasn't manipulated or that some DNS Server in the chain is sending malicious responses, even if they had DNSCurve.

If the root was using DNSCurve, a request to the root would be authenticated, and so on all the way down for each domain that uses it. The recursive resolver would have authenticated responses from each authoritative nameserver from the root on down.

The recursive resolver could then provide a different response to the client, but the client could use DNSCurve to authenticate its DNS server as well, so the client only gets malicious responses if it configures a malicious DNS server.

And that would compromise anything. What happens to DNSSEC if the attacker replaces the client's DNSSEC root keys with the attacker's?

DNSCurve doesn't authenticate the records themselves. A malicious DNS Server can provide simply wrong responses and you cannot notice. There is no way to tell if a provider gave you a bad response.

With DNSSEC the DNS Server also has to advertise different keys, which is something you can notice in your resolver and alert too, for example if you already know the key is different via a side channel or you communicate with another resolver and they got a different key.

DNSSEC makes such manipulation obvious and also prevents in-transit tampering. Coupled with DoH/T you get all the benefits of both.

> DNSCurve doesn't authenticate the records themselves. A malicious DNS Server can provide simply wrong responses and you cannot notice. There is no way to tell if a provider gave you a bad response.

Sure there is. You do the recursion yourself and compare the result. If you do this 100% of the time, i.e. run your own recursive resolver, there is no need to even have a third party recursive DNS server that could potentially send malicious responses. If you do it a lower percentage of the time at random, or for specific queries you're expecting interference with, you detect the interference and know not to trust that DNS server anymore.

Comparing keys in DNSSEC is no better than this. If a MITM attacker has altered your root keys, the attacker can forge responses from any DNS server you use, unless you're using something that actually authenticates the recursive resolver (whether DoT/DoH or DNSCurve), at which point you can compare the query responses again and no longer need to compare the keys or use DNSSEC at all.

> DNSSEC makes such manipulation obvious and also prevents in-transit tampering.

Which is one of its flaws. Sometimes you want friendly in-transit tampering. With DNSSEC there is a fixed root of trust that everybody has to follow and nobody can choose for themselves or alter for a specific subset of the tree.

>You do the recursion yourself and compare the result.

I was talking about during recursion. Plus this is what I mentioned in my previous comment. This is about someone injecting responses on the network level and blocking proper communication or even having taken over an IP via BGP hijack, in which case the NS record might point to the correct IP but a malicious DNS server would be responding.

DNSSEC would detect this failure mode.

>Sometimes you want friendly in-transit tampering

In which case you likely have your own PKI to manage HTTPS MitM as well, so it shouldn't be an issue to run DNSSEC.

> DNSSEC would detect this failure mode.

So would DNSCurve.

If the root servers were using DNSCurve then you would distribute their public keys in the same way that you distribute their IP addresses, over some secure side channel such as your operating system's software update mechanism.

Once you have the public keys of the root servers, no one can impersonate the root servers to you without their private keys. The root servers can then securely give you the names of the gTLD nameservers. If they use DNSCurve, their public keys are encoded in the names of the nameservers and you can communicate securely with them as well, and so on down the chain.

Hijacking BGP doesn't allow you to impersonate any of the authoritative servers that have a chain up to the root using DNSCurve without having their private keys. You can also pin the public keys of any nameservers that don't have a chain up to the root for the same benefit for that subtree, e.g. if some gTLDs used DNSCurve but the root didn't, or to use between your clients and your company's authoritative DNS servers for your own domain.

> In which case you likely have your own PKI to manage HTTPS MitM as well, so it shouldn't be an issue to run DNSSEC.

This is regularly not the case. For example, sysadmins regularly map the most common tracking domains to a black hole in the resolver on the local network or local machine without doing any kind of HTTPS MitM.

>For example, people regularly map the most common tracking domains to a black hole in the hosts file for dnsmasq on their internet gateway without doing any kind of HTTPS MitM.

This behaviour doesn't break under DNSSEC; the blackholed domain either blackholes or the resolver fails due to the bad signature and effectively blackholes as well.

>If the root servers were using DNSCurve then you would distribute their public keys in the same way that you distribute their IP addresses, over some secure side channel such as your operating system's software update mechanism. [...]

And what does that gain you over DNSSEC+DoT/H other than being non-standard?

> This behaviour doesn't break under DNSSEC; the blackholed domain either blackholes or the resolver fails due to the bad signature and effectively blackholes as well.

If you give an address that always sends back ICMP unreachable messages, the client fails immediately and continues to load the rest of the page, but DNSSEC proscribes that.

You could refuse to send a response for those names, but then the client has to wait for the timeout. You could send a response with an invalid signature, but then the client should discard it and continue to wait for a valid response, and you still have to wait for the timeout.

There are also circumstances where you want to return a specific address, e.g. so that attempts to send traffic to that address can be monitored, and redirecting the address doesn't work because it could be a shared host using SNI and you don't want to affect every name pointing to that address.

> And what does that gain you over DNSSEC+DoT/H other than being non-standard?

It's simpler, more efficient, lower latency, has less attack surface and can't be used as a DDoS amplification vector.

And if you want something standard, why not standardize on DNSCurve? Using DNSSEC over that is only the sunk cost fallacy.

>DDoS amplification vector.

How would a TLS-using protocol be used as a DDoS amplification vector?

>If you give an address that always sends back ICMP unreachable messages, the client fails immediately and continues to load the rest of the page, but DNSSEC proscribes that.

You can return resolver errors or no data, there is plenty of options for DNS blackholing.

>There are also circumstances where you want to return a specific address, e.g. so that attempts to send traffic to that address can be monitored, and redirecting the address doesn't work because it could be a shared host using SNI and you don't want to affect every name pointing to that address.

You'll need a PKI for that anyway so you can deploy DNSSEC root keys.

> How would a TLS-using protocol be used as a DDoS amplification vector?

Turning off UDP DNS would break everything that still uses it but adding the DNSSEC records makes the UDP responses a DDoS amplification vector even if some clients use TLS.

> You can return resolver errors or no data, there is plenty of options for DNS blackholing.

DNSSEC validates NODATA responses and clients can respond to resolver errors in various ways that amount to more timeouts.

> You'll need a PKI for that anyway so you can deploy DNSSEC root keys.

That's assuming you want to MitM the connection rather than merely log the attempt before dropping it or record it for traffic analysis even if you can't MitM it.

So basically, DNSSEC is like signing an email with a PGP key, and the others are like encrypting an email with PGP ?

Similar, yes, but it's not a perfect analogy.

In the DNSSEC case, yes, that's akin to the same thing.

In the other, PGP is both encrypting and authenticating the data, then sending that over untrusted email servers. DoH, DoT, et al, are encrypting the channel, and authenticating the endpoints, but not authenticating the data.

Full DNSSEC eliminates the need to have a trusted cert supplier. You can make your own very and the DNSSEC system will be able to validate you are you and not someone else in the system.

No, "full DNSSEC", in the hypothetical universe in which browsers ever supported DANE, simply moves you from having to trust CA's like LetsEncrypt to having to trust the registrars and the world governments that have (often de jure) control over domain registration. DNSSEC does not eliminate centralized external trust anchors; it depends utterly on them.

† (spoiler: Apple, Google, and Mozilla dabbled with it and then rescinded their support; Mozilla and Google have both stated, Google more formally than Mozilla, that DANE isn't happening)

As long as DV certs exist the registrars are trusted anyways[0]. DNSSEC + DANE, for all its faults, would at least reduce the set of trusted actors by cutting CAs out of the chain.

[0] Yes there's CT to help catch dishonest registrars, but a similar regime could be applied to registrars directly to force transparency around changes to TLSA records.

Adam Langley explains in "Why Not DANE In Browsers" that this is not in fact the case, and that DANE will ultimately just expand the number of trust anchors; you can't even get things narrowed down to just the governments controlling your records.

Further: a mis-issuing CA can be put to death (as happened to the largest CA when Google caught them mis-issuing). You can't revoke a TLD.

Meanwhile, CT actually exists today and is meaningfully combating misissuance, and obviously does not rely on DNSSEC to function.

I was speaking more in a hypothetical sense, but you're right. The DNS as currently implemented is sufficiently broken so as to preclude securing it.

> Adam Langley explains in "Why Not DANE In Browsers" that this is not in fact the case, and that DANE will ultimately just expand the number of trust anchors

This is false. That article makes no such claims.

There are two ways that you might wish to use DANE in a web browser: either to block a certificate that would normally be considered valid, or to bless a certificate that would normally be rejected. The first, obviously, requires that DANE information always be obtained—if a lookup failure was ignored, a network attacker with a bad certificate would just simulate a lookup failure. But requiring that browsers always obtain DANE information (or a proof of absence) is nearly implausible

That paragraph does not claim DANE expands the number of trust anchors.

As magila stated, registrars are already a trust anchor for domain validated certificates. Trusting a certificate directly via DANE vs through a domain-validated certificate doesn't change that. It does, however, cut CAs out of the process, which reduces the number of trust anchors.

If you can't use DANE to block certificates that the WebPKI says are valid, then you're stuck trusting both DANE and the CAs. Browsers don't trust DANE today. Ergo, adoption of DANE would expand the number of trust anchors.

Assuming we need to keep backwards compatibility indefinitely that's true, but that still wouldn't expand the number of trust anchors. DANE isn't a new trust anchor, it's just a more direct way of trusting preexisting trust anchors (DNS registrars). Even if you don't use or support DANE you still need to trust the registrars.

No, that is false. DNS registrars do not sign CA certificates and, without DANE, are not trust anchors in the WebPKI. And, of course, with DANE, they would essentially gain that status. This is a plain fact, but you can reason your way to it axiomatically by (again) considering how trust would be rescinded: Google singlehandedly killed the web's largest CA after a misissuance, but obviously cannot do that to .COM in a DANE world.

When your argument starts depending on redefinitions of well-established concepts, that's a sign that you should reconsider it.

I think we are getting mixed up in this thread over multiple senses of the term "trust". One sense is PKI. Ajedi32 is referring to a different type of trust.

Everyone who uses .com must trust the authority for .com, because that registry's name servers are what delegate control of all domain names in the TLD. Every time you resolve a domain name like "example.com", you are relying on the name servers for ".com" to serve correct information.

If the registry was malicious (or if an attacker compromised it), then the registry could easily seize control of any domain name -- it could rescind the delegation and publish whatever DNS records it chooses, including the DNS records necessary to obtain a domain-validated certificate.

It is correct to say that we "trust" TLD authorities because they can do these malicious things, but they commit to behave in a certain way. We trust TLD authorities in the same way that we trust certificate authorities only to issue certificates following a certain process. Both of these actors are capable of fraudulently obtaining certificates: the CA can mis-issue a certificate directly, whereas the TLD can seize a domain's DNS and trivially procure a domain validated certificate (from a legitimate CA).

This is what I believe Ajedi32 means when referring to "trust anchor" (using the term informally). DNSSEC is not adding new trusted entities, but is rather adding PKI around an existing trust relationships: a child DNS zone (e.g. example.com) always needs to trust its parent zone (e.g. the .com TLD). In the PKI sense, I agree that it would be adding new trust anchors, but those trust anchors would simply model preexisting trust relationships that don't use PKI.

On that note, we also need to trust the Internet root name servers that point to the name servers for the TLDs.

Again, this is a redefinition of the concept of a WebPKI trust anchor (or, for that matter, of a "trust anchor" in any PKI; it would be equally confusing to describe the Linux kernel as a "trust anchor" in a secret storage or XML signing or inter-services authentication PKI).

If you want to use an idiosyncratic definition of a term, that's fine --- I won't, but I can at least follow the argument. But what you can't do is say "that citation you provided does not say what you said it does" when it clearly does using the mainstream definition of the term. It's especially fallacious to pull out this semantic argument about a reliable source that generates a surprising conclusion about trust anchors!

DNSSEC adds trust anchors to the Web PKI.

Obviously, I disagree with the argument that we "need" DNSSEC to securely issue certificates, but the rest of this thread adequately captures my rebuttals to that argument.

If you insist on such a narrow definition of the term "trust" then yes you're technically correct. But it also reduces your entire argument into one of semantics; there's no security impact to adding a new "trust anchor" as you're defining the term.

No, sorry, you're not getting away with that argument. We're not debating "trust"; we're debating "trust anchors". "Trust anchor" is a term of art with a specific meaning, and you can't pretend I'm the one trying to exploit a technicality when you've built an argument whose premise is an idiosyncratic redefinition of the term.

Besides that, you were just plain wrong, twice (you doubled down when I showed the quote that refuted your claim). It's fine to be wrong; I'm wrong all the time! But stubbornly refusing to acknowledge when you're plainly incorrect to the extent where you redefine words is not a good look.

Okay, that's fair. You've won the semantic argument, I was wrong to argue that DANE doesn't add new "trust anchors".

The central point of your comment is still completely wrong though. DANE does _not_ add new trusted actors, and has no significant negative security impact.

"Trusted actor"? Seriously?

That's the term magila used in the comment you originally replied to near the start of this thread before you started the whole semantic debate about "trust anchors". Ultimately, trust is something you place in people and organizations, not inanimate cryptographic primitives.

Ah, you're right, fair enough; I read it as "trust anchor" (because that's the real term). Sorry for snarking.

Reply on news.ycombinator.com