DNSSEC KSK rollover breaks DNS resolution for .nz domains(status.internetnz.nz) |
DNSSEC KSK rollover breaks DNS resolution for .nz domains(status.internetnz.nz) |
It certainly feels like the wrong way of solving problems (ramming more into the domain registry always seems like a bad option). Is the technology dead or destined to fail?
Edit: rationale: dnssec solves domain validity, but https tls solves almost the same problem but has better backing (azure said they don’t support dnssec and recommended tls as a better alternative). Dnssec also does not solve bgp hijacking, which combined with ip based tls signing servers moots any value dnssec has - sure you could registrar lock your domain via dns (preventing letsencrypt signing things), but if a threat actor has the capability to bgp hijack to perform such an attack and is targeting you, you probably have bigger issues elsewhere.
Both BGP and certificate issuance have bootstrapping problems, which are handled today by imperfect TOFU-like solutions. DNSSEC is, IMHO, perfectly positioned to solve both of those problems. I.e. use certificates all you like, but verify them by looking up the TLSA record in the DNS using DNSSEC. No need to trust CAs. BGP could possibly use the same solution, using the reverse lookup .arpa DNS space.
DNSSEC is the building block from which secure certificates and BGP routes can be built, without the ad-hoc CA system we have today.
If Comodo knowingly misissues a Google Mail certificate, Google will nuke them from orbit, as it has done in the past with other major CAs. Google can't do anything about .COM mis-signatures.
Thankfully, practically none of .COM is signed.
Compare to DNSSEC which are designed to have single supplier. If a TLD registrar goes bad, what is going to happen? Moving to a new TLD is a huge deal, and affects everyone, including your customer. And browsers can't really ban an entire TLD like they ban CAs.
So yes, both CAs and DNSSEC have some problems. But one of them is pretty good and getting better the time (deprecation of old crypto, short-expiration certificates) while the other is stuck with ancient crypto, constant technical outages, and no chance of improvement.
As with any PKI, the RPKI isn't effective if you don't use it, or if you use it in a merely advisory capacity and then routinely ignore its advice. And as with DNSSEC of course if you actually use this technology and people screw up (which will happen) there are outages, which would not have happened if you used no security technology.
In addition though, RPKI signifies business arrangements and so you can imagine real world policies may vary slightly from what RPKI says. For example, suppose you're a Canadian ISP and Big US ISP A says they're not going to use Long Haul provider X any more from Thursday. Sure enough the RPKI entries for ISP A via provider X expire after Wednesday. As of 00:05 on Thursday, 40% of routes for ISP A on your systems transit provider X. Should you kill those? Your customers would perhaps be pretty angry if the ISP A CEO later clarifies that "obviously" they meant from start of Business Hours. How about at 12:00 midday? How about the Monday after ? What if two months after this announcement, having left these routes in place you discover provider X were hijacking ISP A traffic and this was never merely a mistake, it was leverage ?
This seems like a pretty unreasonable complaint. Dnssec also doesn't stop phishing. Or nukes.
So you either accept that TLS is the global maxima for security and world governments can basically permanently compromise the internet, or you build private PKI systems, or you want something like DNSSec. And DNSSec is something like DNSSec.
Speaking as someone who most people consider a DNS expert and actually did help develop and deploy something substantially additive that is in widespread use today (DNSCrypt). ¯\_(ツ)_/¯
Same cars has issues with drivers being locked inside if the car goes into the water. That is a bug.
Is the solution to abandon locks on cars, or is the solution to fix the problem of the car doors staying locked when submerged into water? The security system by now is fairly advanced and addressing issues with accidents is a real problem. No one however would sell cars without locks.
The natural progression is for hijackers to then carry buckets of water or spray cans and target the sensors that detect a water scenario.
Supplementary question: Why do so many sites these days opt for tiny font-sizes in some shade of pale-grey on white?
With DNSSEC zones are controlled and signed by a single authority, and for CCTLDs that authority is controlled by ... the government. If they wanted to produce a malicious signature and serve it narrowly to a targeted victim ... that's quite doable with little in the DNSSEC system to prevent it.
While it's true that there many TLS root cert operators and some probably could be compromised by a government (though I wouldn't say "trivially"), there is also a gigantic mutual destruction pact in the form of certificate transparency that means all certs issued are visible in transparency logs and there are quite sophisticated technical and social controls in place to detect malicious certs. The cert operator would be imperiling their business and future trust in a way that isn't as true for DNSSEC.
Certificate transparency is cool, but it's not clear it really works for many classes of devices (particularly devices that only use one network like gaming systems or TVs). The global adversary just compromises the channels used to obtain the transparency logs and to report violations. It seems to work for mobile consumer devices like cel phones, because these devices naturally connect to many different networks, of which only some are compromised.
Users who are concerned about a government like the United States can use DNSSec to prevent a threat like this by using a non-US based TLD that employs DNSSec, and by running their client in a mode that requires valid DNSSec records for their domains. Of course, such services would practically need to be located outside of the country of concern as well.
I'm only half joking.
Google is very enthusiastic it seems about things which force users to use Google Chrome, and very unenthusiastic about users doing anything easily from the command line because it has the notable quality of removing a place you can show ads.
And what I note about the whole OAuth ecosystem is that you wind up having to puppet a web browser in order to get through sign-ins and the like. "Oh but you do it infrequently" says every single company implementing their own bespoke way of entering a username, password and TOTP while salivating at all that unused <div> space for ads.
The story of Ethernet is kinda interesting. Invented in 1974 at Xerox PARC, the inventors started a new company called 3COM in 1979, and worked with IEEE, as well as DEC, Intel, and Xerox (called the DIX - I'm not kidding) for all of them to join forces and support one new standard. IEEE project to standardize it started in 1980, and formal standard publication happened in 1983. International (ISO) publication was in 1989.
Business decides what becomes the new standard, because the biggest businesses are whom everyone is dependent upon. So the biggest companies do set the new standards. Google has been doing that for years, using its search market dominance and custom browser as carte blanche to shape the web as it sees fit. CloudFlare has come in the back door, and doesn't have anywhere near the same influence, but does control a powerful market segment that is growing. Add in the cloud providers, and that's most of whom actually matter in terms of where the web goes.
Where the "internet" (sans web) goes is, I think, more up to the operating systems and ISPs. But since everything has been pushed into the web to avoid the manipulation of the "middle boxes" (ISPs and corporate networks), the end result is the people who control 'the web' (Google and CloudFlare) can now dictate terms.
Whether or not an ip address goes to the correct computer is totally unrelated to DNS, so i'm not sure why anyone would think that has anything to do with a dns security measure.
The relavant security thing for bgp is called rpki.
What else would we expect from an advertising company.
Solutions exist within problem spaces, or "paradigms", a car lock is only useful for a specific set of things i.e. deterring thieves or unwanted entry e.g. at stop lights.
What I really want is a force-field to keep people and highway debris out while driving around, and a secure storage solution while not in operation.
If you could sell me a force-field car with a retracting tent, and it were safer/had less issues, I might not care to have locks on my car.
See also - door-less/open air vehicles. Car door locks have some pretty serious issues. There are some problems they just can't solve.
Certificate Transparency came into the picture around 2013, by which time https was fairly old. Public resolvers like google, quad 9, and cloudflare could create Certificate Transparency for dnssec today if there was a demand for it.
If the attacker want to bgp hijack the authoritative server they will need to bgp hijack the TLD name servers that holds the DS posts for the authoritative server.
If the attacker want to bgp hijack the TLD name servers they will need to bgp hijack the root server that holds the DS posts for the TLD name servers. This they can't do because the root servers keys are hard coded into revolvers.
With CAA records you can also lock it down to a specific user and method (RFC 8657). How will you solve that with BGP using acme?
For ccTLDs you could hope, especially if you are a citizen of the country encoded and it's a democracy, that you can vote for governments who require the TLD registrar to meet your needs. Will that work? Well, no worse than them ensuring adequate drinking water and that sort of thing.
TLDs seem primarily to be chosen for existing popularity, so no matter how badly COM is run, people will insist they want a .com domain, and then complain about how badly the TLD is run. I don't see DNSSEC ever making that substantially worse.
Suppose you paid $50 last year for theamk.example - what sort of abuses could the example TLD already do - ignoring DNSSEC entirely ?
Somebody has decided to register the\u{0251}mk.example, the\u{0431}mk.example and now the\u{ff41}mk.example - your TLD's policies say that they take this sort of thing "very seriously" and they try to ensure that after they've been paid in full for the domains they get around to removing these bogus sites used to attack your customers just as soon as you file the necessary paperwork, plus 90 days admin.
They might tell you that somebody else offered them $5000 for theamk.example and so too bad now it's not yours any more. Can you fight them? Yeah, and eventually you might even win, but meanwhile your domain isn't working. I hope you didn't need that.
Oops due to an "error" theamk.example just doesn't resolve any more. Don't worry though, they aim to fix such errors within 45 days. Or you can pay for $25 Expedited Support ?
Oh no, apparently "Theamk Inc." in Beijing says you are squatting on their rightful trademark which they registered last week in Bulgaria apparently. The TLD registrar has decided to immediately transfer your domain to them.
For an example, sr.ht is hosted by Haitian TLD but has Let's Encrypt CA. Thanks to CT logs, I trust that the connections are secure, and when I download software from it I am getting it from the rightful place. (Or not getting this at all because website is down. That's a nature of the web, things break)
But with DNSSEC? No assurances at all. Owner of .ha can be coerced or bribed by $(your least favorite nation) and this may never be detected, especially if this is a targeted attack to specific addresses. And even if detected, there will _still_ be people saying, "hopefully this does not affect me, I won't move domains and risk my search traffic".
And that's the reason that DNSSEC scares me and WebPKI does not.
Not only is your claim obviously not true in principle, we know it's not true in practice, disrupted DNS causes real issuances which are let's say... suspicious. They're not mis-issuance under current policy because the Web PKI trusts the DNS, but they would trigger exactly the scenario you believe can't happen.
For more fun diving into this topic, I can recommend a famous old presentation called the "Everything you Never Wanted to Know about PKI but were Forced to find out", and godzilla crypto tutorial written by the same author (Peter gutmann). The certificates in browsers has had a long history of problems and ill designs. People did not like them, and they definitively did not like them when they caused major issues.
I’m not sure what you’re basing that on but every claim is the opposite of my experience back then. Even in the 90s it was expected that you used HTTPS for any site selling things, for example, as the credit card companies would block a business who let numbers go over the network in plaintext.
Early on there were concerns about performance but that was mostly over by the turn of the century for all but large file transfers. The primary drawback was the cost of a certificate back then.
It should also be mentioned here that credit card numbers as a security token has actually slowly been phased out in favor of other forms of payment systems online, and many banks today implement additional security requirement if you pay with a credit card. Black market with stolen CC numbers, despite https use by web stores, used to be one of the biggest issues with the internet, so even with all the stores using https it wasn't a solution to that problem.
I remember people talking about performance issues with https until the early 2010. "Every single micro second slower means reduced sales" was something people was very concerned about. I even heard it from people during an IETF meeting. It was talked in similar tone to how people today talk about SEO.
Everything you Never Wanted to Know about PKI but were Forced to Find Out:
<http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf>
Godzilla Crypto Tutorial:
The premise of CT isn't that every device is watching the logs in real time, such that your set-top box is somehow using it.
For a device like a router, if the router doesn't check the logs itself, and a global adversary compromises the TLS update channel for the router, and starts distributing malicious firmware... If the router itself doesn't report the violation, for how long might such a compromise go undetected? Is there any reason to think it'd ever be detected?
CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients. For homogenous configurations (like the implementations of AWS, Azure, or GCM, or the deployment of routers, IOT devices, or gaming systems), it seems like a competent global adversary would simply figure out how to go unreported for that configuration, and nobody would particularly check.
Unless I'm misunderstanding you, this isn't really how CT works: the expectation for clients under a PKI with CT is that the presented certificate is already present in one or more logs, meaning that it's never (or more accurately, never has to be) the client actually doing the reporting. Reporting is left to separate monitoring parties.
In other words: a global adversary cannot surreptitiously use a novel CA against a particular configuration; they must first make themselves visible to one or more CT logs. Failing to do so means that their CA will be rejected outright by the client (or accepted by the client if the client doesn't do CT, but still with a loss of stealth).
Operators who host infrastructure can and should be monitoring issuance in CT logs for domains they operate, which will allow them to identify and react to any unexpected issuance for those domains.
If Verisign knowingly missuses .com root certificate, Google could nuke them from orbit by making it public. That is the whole purpose of certificate logs. Verisign operate on trust and they are also certificate authority.
The damage to Verisign if they lost their status as certificate authority and as a trusted company would create so much fallout I am doubtful that ICANN and DNS would be left without major scars.
I don't think you've thought this through all the way.
The difference is that DoH protects transactions and DNSSEC protects the authenticity of records. It's perfectly possible for a DoH server to feed you bogus cached records; you have to trust the DoH server you're talking to, where you wouldn't have to do that if all the records on the chain of lookups you're doing are signed with DNSSEC, and you're running DNSSEC on your local system rather than a stub resolver than talks to full resolver server you have to trust (this is an uncommon set of circumstances and in practice you have exactly the same server trust problem with DNSSEC that you do with DoH).
Muddying the waters further, the attacks DNSSEC protects against overlap with the ones DoH protects again, so that if the whole Internet managed to switch to DoH, you'd have bottom-up built 95% of the security feature DNSSEC is attempting to provide (DoH has massively better deployment stats than DNSSEC, so this is plausible).
It's better to think of DoH as one of a catalog of different arguments that together make a clear case for sticking a fork in DNSSEC and calling it done.
This is particularly true if your security model also includes things like TLS to secure your communications with whatever domain you just resolved. In that scenario, the features DoH provides that DNSSEC does not (e.g. lookup confidentiality) are still quite useful, while the 5% of DNSSEC use-cases that DoH doesn't cover are essentially redundant if not better provided elsewhere in your protocol stack.
Is this actually true where it matters? (i.e. the root servers and authoritative servers for TLDs)?
A reminder that DNSSEC's "cryptographic security" coalesces to the single AD=true bit in the DNS header by the time DNS responses hit your browser; DNSSEC is a server-to-server protocol. So in almost all cases, save those in which nerds have run full recursers on their desktops, the server trust situation with DNSSEC is largely the same as that of DoH.
According to the original DNSSEC RFC, RFC2065, the purpose of DNSSEC is to provide data origin integrity and authentication. It also states "In addition, no effort has been made to provide for any confidentiality for queries or responses. (This service may be available via IPSEC [RFC 1825].)" IPSEC didn't end up providing that role but DoH does. It doesn't address the issue of data origin integrity though.
With DNSSEC, I know that anyone asking for IP addresses of my web server will get the correct address, and in the future it may be possible to use TLSA records (and/or HTTPS records) so that the user’s web browser can be certain that it is connecting to the correct site, with the correct key. The only weak point is that the user might be using a DNS resolver which may be correctly checking the DNSSEC signatures, but the DNS replies, sent from the resolver to the user, are not signed, only “authenticated” by the AD bit. (This is where DoT – or even, blech, DoH – might actually help.) Or the user could run their own local resolver with no untrusted path between their device and their resolver, closing the gap completely.
Contrast that with using no DNSSEC, only DoH (or DoT). The user asks the resolver for the IP address (and possibly HTTPS/TLSA records), and the resolver asks the authoriative DNS server for the information. But the whole conversation between the resolver and the authoritative DNS server is completely unsigned, and can be manipulated at will by any middlemen. Also, it is not even TCP (which is hard, but not impossible) to manipulate as a man-in-the-middle, but DNS is most often UDP. But let’s say there is no manipulation here. How do you trust the identity of the resolver? Because they have a nice certificate from “Honest Achmed's Used Cars and Certificates”¹, which says they they are indeed the DoH resolver the user has configured? The same problem also applies to the web site certificate; how can you trust it, when any CA in the world can issue any certificate at will?
Which is where you get to the crunch point though: this is not a digital problem, it's a social problem. The way you establish trust is by generating a suitable preponderance of evidence that someone is who they say they are.
On the internet we outsourced this to a couple of big players who broadly benefit from decent standards, but the ultimately it is just "might makes right" - Google says they don't like you, your business ceases to exist.
The trouble is some of our standards in this area are complete junk and so widely implemented they're near impossible to change - i.e. why CA certificates don't have a limited domain scope (technically yes, they can, but it's an extension and a lot of implementations don't check it to the point you can't rely on it at all).
IMO this is where open-source and it's anti-government bent has to some extent done a huge disservice to the internet. The vast majority of internet traffic people need to be "no questions secure" is traffic that interacts with government or government-recognized entities and their associated legal systems. The identity people are trying to establish is most frequently "Are you under a legal jurisdiction providing me recourse if dealt with unfairly, and honestly representing yourself?"
Which incidentally is why I wish like hell the Signal project would create a paid enterprise offering to fund itself. I want my bank to use Signal to send me things, and I want some assurances around proving that's who it is.
If all else fails, ICANN runs the root servers more or less, and is based in the US, and subject to being compelled to make bad signatues of tld glue records.
Secondly, the root server operators have no control over the cryptography. They get a zone file and they serve it.
ICANN only runs the key generation ceremony which is scripted to prevent any single entity from tampering with the keys. ZSKs are generated a few months in advance and used by Verisign (the root zone maintainer) to sign the root zone. No one gets to see the private part of the KSK. So there is no way to compel ICANN to produce bad signatures.
Finally, glue records aren't signed!
Ok, well back to compelling Verisign. Certainly they are able to sign zones, although that authority flows from ICANN.
> Finally, glue records aren't signed!
If glue records aren't signed, then why wouldn't an adversary simply modify the glue records to omit the DNSSEC content? Maybe you're making a technical argument that the whole root zone is signed, not its individual components?
I don't check or audit my CA's and don't think most people do either. Wouldn't be surprised if more than one of these has been compromised in some fashion already. It only takes one and there's plenty to target.
The next thing you'd need is a mitm attack and again that's entirely possible for a nation state to pull off at scale.
The people responsible for running the root stores do. And when CAs screw up, they are nuked from orbit--this has happened a few times. And they can be proactive: when Kazakhstan announced they would require all TLS connections to be MITM'd, the browsers promptly added the MITM certificate to the root store with the explicit distrust bit set, meaning that the resulting certificate error can't be clicked through, effectively breaking the internet if you tried to use that for MITM (which put the kibosh on that plan immediately).
And for another thing, I wouldn't trust the people who run the nameservers any more intrinsically than CAs. After all, the TLD that runs most of the commercial internet (.com) is run by a company that had problems when it ran a CA. There's no way to route around an untrustworthy TLD operator, and it needs to be recalled that many TLDs are literally run by state governments. And several of those governments believe the privacy of their citizens to be a bug, not a feature; giving them a more prominent role in securing privacy is not a good thing.
The CAs that got the boot were detected because they issued certificates that were obviously invalid, for example for domains like example.com (Symantec), test.com (Certinomis), or domains that didn't even exist (Camerfirma).
A CA that issues an unauthorized certificate for some random domain won't be detected unless that domain's owner is monitoring CT because no one else knows if the certificate is authorized or not.
So please do monitor CT for your domains and don't just rely on root stores and security researchers to do so.
CT provides a guarantee like: "hopefully one of those devices will eventually connect to a non-compromised network and report the prior compromise". By observing the lack of such reports, we can be reasonably confident compromises of size N>millions are not happening, but it's difficult to reason about what compromises may be happening at small N.
Such an attack would be detected if some clients reported which certs they actually saw the next time they connected to an uncompromised network (as Chrome does) but if no clients report, such an attack could go undetected.
The fact remains - an adversary with a CA private key that can mitm all of the internet connections for a device can forge a fake CT log and go undetected, if that clients never uses a non-mitm network again.
Source: I work in this space
> If the installed version of Chrome has not applied security updates and has been unable to obtain an updated CT log list from the Component Updater for 70 days or more, then CT enforcement will be disabled.
That means a global adversary need merely block the update channel to targeted devices and wait. How will a Smart TV behave?
SCT auditing only takes place if a certificate has SCTs. SCT auditing checks to make sure that the log really published the certificate. If it didn't, then the bad SCT is reported to Google so the log can be kicked out of Chrome.
Thus, I really care about LE getting the right IP, I don't care about random users' DNS getting hijacked because their browser will reject the missing/invalid certificate.
The right way to think about this CA issue is this:
* The largest, best-funded, savviest security teams in tech are, like the rest of tech, not signing their domains; the major TLDs are overwhelmingly not signed (there is low single digit uptake in .COM for instance, and what's there is overwhelmingly not big companies but rather random domains signed by registrars that auto-sign). Nobody who's actually targeted for CA misissuance attacks uses DNSSEC to mitigate that threat.
* The WebPKI already has a system in place to guard against misissuance that, unlike DNSSEC, actually does work: Certificate Transparency. So if you're actually concerned about CAs not issuing bogus certs for you, match your revealed preferences to your stated ones and set up CT monitoring.
I would appreciate it if you would update your other comments in this thread clarifying that, as we both now agree they are incorrect.
Meanwhile if DNSSEC's vision is ever fully realized, you will lose that control entirely. There is no CT there, and even if it was build somehow it will be useless as it has no "teeth".
This is a false dichotomy. DNSSEC secures DNS records, it doesn't prevent logging certificate issuance.
> Certificate transparency is cool, but it's not clear it really works for many classes of devices
Smart TVs aren't some gotcha I'm throwing in at the end. It's literally the first thing I said about CT. CT works ok for mobile phones, laptops, and other devices where you can make certain assumptions about multiple networks and frequent updates. If you want a technology that doesn't require these assumptions, you want DNSSec.
That matters because, as the person you were replying to explained, there’s no plausible way to build such a thing. We have CT because the browser developers insisted on it and they control the clients but DNSSEC doesn’t have an equivalent party with that kind of leverage.
So... Governments like the US and China can fake the entries by using their police forces to seize the private keys?
SCT has the same set of problems as TLS - any log will do, not just logs from countries you trust.
So yes, it's true that if an adversary can permanently silo off a client, it can prevent log misbehavior from being detected, either by blocking the reporting of audit failures, or by presenting a completely different view of the log to to the client. However, in many cases it would be impractical for an adversary to keep up such an attack forever, so CT still has value and I'm a huge fan of it. But it's true it can't stop literally all attacks.
Source: I run the CT monitor which has detected misbehavior in multiple CT logs.
Why do you think this isn't possible?
CT logs are used by CAs, not clients. A 'fake' log isn't a thing.
I want a version of Web PKI strong enough that I can turn off my tablet for a year, turn it back on in a coffee shop, apply automatic updates, and not have my web traffic monitored, even if I'm gay and the coffee shop is in Saudi Arabia.
From what I can see, DNSSec+CAA+.com+US CA+US hosting for the Android update server does the trick. No version of CT does.
It's late and I maybe haven't been super constructive here, but I think when you try to write out the actual assumptions behind CT as the whole solution, you realize you've got something that mostly works assuming assuming assuming - and worse, we'll never do any better, because those assumptions are fundamental technical limits. DNSSec may be ugly but at least its problems (like validators failing open) are just deployment issues, not fundamental technical issues.
I'm sick and tired of using technologies that provide security or correctness subject to a long list of preconditions and ways for folks to tell me I'm using it wrong. To build secure systems, we need technology that provides correct security without so much asterisks and fine print.
To begin with, CAs are allowed to operate logs themselves, so the minimum number of independent parties is 2, not 3.
Second, CT log private keys are not particularly well-protected. They are not stored in HSMs. One log's private key has been presumed compromised since 2020 because the server running the log was pwned via a vulnerability in the Salt configuration management system. SCTs from this log are still accepted by Apple (and by Chrome, until earlier this year) for satisfying the minimum SCT requirement.
Rather, CT provides security by using a Merkle Tree so that SCTs can be audited. In theory, clients can demand proof that an SCT is really included in a log, and gossip tree heads with monitors to ensure that monitors have the same view of the log as them. If an SCT fails auditing, or a log is found to have presented inconsistent views of its Merkle Tree, this can be detected and the log can be distrusted. In practice, this is quite challenging. Apple currently doesn't audit SCTs at all; Chrome probabilistically audits a subset of SCTs.
> The fundamental difference is that with TLS you have to trust ALL certificate issuers, but with DNSSec you only have to trust your TLD and your certificate issuer.
It's probably fair to say I've been a bit over assertive about CT, but it's all in the margin to me. No amount of technical complexity can turn community trust into direct trust. TLS is a community trust model and DNSSec is a direct trust model. The fact that CT is a pretty good community trust model and that browsers have (so far) done a pretty good job at keeping the CT community small is interesting, but it doesn't turn community trust into direct trust. So while I'd agree it's an incredibly tedious tangent, I'd say it's tedious moreso because the pro-CT folks are missing the forest for the trees than for any technical details about CT.
Edit: because community trust fundamentally relies on the notion of the community taking action against bad actors. Whether it's a CA or a CT log provider, and whether it's malicious action or a bug or just ceasing to do business, community trust has a time axis where membership in the community changes and notions of keeping devices up to date and political struggles ("too big to fail") and the like that simply aren't needed in direct trust.
(Not that I'm a DNSSEC user myself, my feet aren't bulletproof)
Particularly when the software in question is running on somebody else computer, proprietary software and OS (or OS modules), unknown patch versions, etc.
I'm not looking for a debate; I'm just calling out things you say that are misleading and moving on. You're welcome to dispute my callouts! I'm satisfied that the thread establishes which arguments are credible and which aren't.
You're not a fan of DNSSEC and prefer CT. When faced with examples where CT doesn't cut it, you refuse to discuss the big picture, pounce on incorrect details, and then resort to claiming your opponents are uninformed or arguing in bad faith.
The bottom line is my original big picture claim, the part that's on-topic for the article - that CT works for browsers on personal computers but not other classes of internet connected devices - it's true! And you know it! But you'd rather debate the details than inform readers about what they actually want to know (the big picture - i.e. that DNSSEC is useful).
I've observed your behavior before on hacker news, but experiencing it directly is eye opening.
Ironically, this actually is a problem for DNSSEC validation! It's the literal reason why Chrome pulled its original DNSSEC/DANE implementation from the browser.
I acknowledge that embedded systems are a difficult place to do the policy-driven cryptographic security that we're talking about when we talk about the WebPKI and DANE. They're difficult for all sorts of reasons and they're difficult for all of software security, not just this. But they're pretty clearly also not a motivation for the deployment of DNSSEC; in fact, they're a sort of worst case for DNSSEC.
That's what this whole long subthread is about. It wasn't a strong argument. The thread has mostly been attempts to lay out why it isn't, without any interesting evidence for DNSSEC's suitability being presented.
