DNSSEC KSK rollover breaks DNS resolution for .nz domains
status.internetnz.nzIn 2020 I scraped fortune top 500 companies for dnssec and found iirc one domain using dnssec.
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.
When criticizing DNSSEC, you can’t assume that the system for TLS certificates – i.e. CAs – is perfect. They both have their weak points and drawbacks.
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.
People say this all the time, but of course the WebPKI has Certificate Transparency, requiring every issuer to register every certificate issued in a globally monitored tamper-proof log, and DNSSEC doesn't. Moreover, the WebPKI got CT because the browser root programs were able to force the CAs to join it. They have no such influence over DNS registrars, many of which are de jure controlled by world governments and will never consent to transparency logging. This very much includes the US, which actively manipulates the DNS for policy ends.
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.
If the issue is the lack of certificate transparency, then add that as a new standard to dnssec.
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.
I've explained several times on this thread already why DNSSEC won't ever get transparency logging.
You said that registrars won't implement transparency logging, but certificate transparency was not created by certificate authoritative. Google added it to chrome, and they could just as easy add it to their own public resolver.
And then what happens? Google stops resolving .COM names? I don't think you've thought this through all the way.
"If Comodo knowingly misissues a Google Mail certificate, Google will nuke them from orbit" - tptacek
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.
That's not at all what "nuke from orbit" means. Google broke Thawte and Verisign. They didn't simply "make it public". Thank you for clarifying this; I could have been clearer. I think the distinction between what's possible in CT and DANE is much more obvious now.
I am 100% not arguing with any of your points, you and I agree absolutely on DNSSEC. However...Comodo don't issue anything anymore - it's Sectigo now. Nitpicky, I know!
DNSSEC scares me. CAs are not perferct but they at least have some measure of accountability. Therr are many stories of CAs being removed from browsers, and many of them ended up ceasing operations whatsoever. The reason for that is CAs are interchangeable, if one goes back I can switch to other with almost no distruption.
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.
The TLD registrar has enormous impact on you regardless of DNSSEC, and people just seem to put up with it, much as they put up with having an awful US state government, or a terrible HOA, or dozens of other problems.
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.
The important stuff is not just websites I host, but also websites I visit. And in all the scenarios you mention, I (and everyone else) would know that it happened very clearly, as it is basically denial of service attack. Even if this is a takeover event with almost-instantaneous replacement with the phishing page, the website owner would detect this and if the website is at least a bit popular, the news would definitely hit the HN top page :)
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.
Web PKI CAs aren't psychic, they just use DNS. So your claim ends up being that you believe DNS answers from the DNS can be tampered with by parties who control those answers (which includes the TLD registrar, this part checks out), but, somehow every Web PKI CA would know if this happened and disregard the results.
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.
You're right of course, but there's progress being made to require multi-perspective verification (do DNS lookups from many different and ideally randomised locations, only issue if you get consensus). It's not perfect, but it's a great step in the right direction.
DNSSEC can be tampered without leaving a trail of evidence. If you MitM DNS for all the outbound IPs a CA uses, the end result of that gets logged in Certificate Transparency. And since 1) sites can and do monitor CT for their domains and 2) browsers demand the certificate has been submitted to CT, we know that e.g. google.com is not MitM'ed.
BGP has its own PKI, the RPKI, so it doesn't need to lean on DNS whereas much of the other Internet systems already leans on DNS so might as well choose DNSSEC.
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 ?
DNSSEC does actually have protection against bgp hijacking. The dnssec root key are (generally?) hardcoded into the resolvers, so even if someone would do a bgp hijacking of the root servers they would still not resolve.
Who cares? If you control BGP, you control the meaning of the IP addresses DNS resolves to.
If the attacker bgp hijacks the record target they need to also bgp hijack the authoritative server that holds the TLSA record (which the client could verify during an attack).
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.
None of this matters. An attacker who controls BGP controls IP routing. They can defeat ACME.
TLSA record can specify what specific hash the certificate must have (DANE-EE). You can't solve that with BGP and ACME. The certificate that you get from acme will have a different hash.
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?
You’re also relying on the client validating DNSSec. I have no idea if/how/when this occurs, or if you can choose to ignore it.
A nit, but the resolver, not the client, validates DNSSEC. The client/stub resolver trusts its local resolver. That always struck me as weird.
> Dnssec also does not solve bgp hijacking
This seems like a pretty unreasonable complaint. Dnssec also doesn't stop phishing. Or nukes.
Where it's a complaint worth making is that every time there's a BGP Hijack there are a series of articles written incorrectly claiming DNSSEC would have prevented it.
What does dnssec solve then?
Authenticity of dns records. Making sure that the dns record points to the correct ip address.
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.
DNSSEC designers screwed up by making rollovers to be atomic. Instead, they should have allowed the responses to be signed by two keys. And a way to specify as a hint which key should be used, so that the zone owner could gather feedback on the rollover safety.
No, DNSSEC does allow for multiple signatures. You can use tools like dnsviz.net to see which key is valid from upstream (if you don’t know how to do it manually).
You can and should sign by multiple keys before/during a rollover. That's exactly how it's supposed to work. The client is to check all, and any valid chain.
It seems like some folks are missing the motivation for DNSSec and suggesting TLS instead. If your threat model includes global adversaries, you have can't rely on TLS because governments can trivially compromise TLS providers and TLS exposes users to the lowest common denominator TLS. The lowest common denominator TLS (ACME DNS-1) and the mitigation to the TLS provider problem (CAA records) are both based on DNS.
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.
That seems exactly backwards.
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.
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. Most companies trust their home country as a matter of practicality.
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.
All the CAs are required to log. You don't have to trust any of them.
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.
Somebody has got to check the logs and report violations. Chrome does, so CT works mostly for the world wide web, because all websites want to work in Chrome.
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.
> 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.
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).
The client has to get the CT log from somewhere, like an update channel (typically TLS). An attacker would compromise both the target and the process by which the client gets CT log updates.
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.
That's not how any of this works. Clients don't download the CT logs.
Clients get pre certificates (which are portions of the log) as claims in certificates. It's correct that they never download the whole log - I'm simplifying for clarity, not out of lack of understanding.
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.
No, because the presented certificate won't have any SCT entries (which are embedded in the certificate), and you can't fake the SCT entries without having access to the CT private keys.
> you can't fake the SCT entries without having access to the CT private keys.
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.
This is why multiple SCT entries are required. Could you subvert all of this with enough effort? Yes, and the same is true of dnssec. Any form of cryptographic validation is only as secure as the control of its private keys, but modern TLS is designed to require you to compromise at least 3 independent parties in the TLS ecosystem to provide a plausible fake. And at that point why not just get the browser vendor to push a fake update to the user that disables TLS validation entirely? You're either doing all validation yourself, or you're trusting someone. Modern TLS avoids you needing to place trust in any one organisation from the TLS perspective, which makes attacks on other infrastructure components much more appealing.
This is not an accurate description of how CT provides security.
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 crucial difference is who decides which cryptographic entities to trust. With TLS and CT, the browser defines the list of entities and if 3 or more of those entities live in a hostile country, you can be compromised. With DNSSec and CAA, the site operator gets to define the list of entities.
Ok. That's an argument you can make. Now go back and make that in the first place rather than diverting everyone down an incredibly tedious demonstration of you making assertive statements that are just factually wrong. There's space to talk about what tradeoffs are reasonable here (eg, if this is something you're concerned about, you can pick a CA that's not in a hostile country, and you can enable certificate stapling at the cost of increased fragility and depending on some level of TOFU), but when you start the conversation by just being clearly wrong and then double down on that when multiple people suggest that you're wrong and point at resources indicating that you're wrong, you're not doing a great job of making that space available.
It's the argument I made at the top:
> 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.
CT trust does not in fact rely on "the community" at large taking action against bad actors. The history of CA surveillance will avail.
Of course it does. CT trust relies on root programs removing bad CAs and root programs and security researchers sharing information about bad CAs with root programs. The root programs, CA, and security researchers are colloquially "the CA community".
This kind of handwaving summary would be more credible if it hadn't been preceded by a long thread where it was made clear you didn't understand how CT functioned, at, like, a very basic level. You entered this conversation stridently equating CT monitoring with things like revocation checking.
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 are looking for a debate, I think. It's the whole thread. You're nerd sniping. It's classic.
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.
It is difficult to make any sense out of your claim that internet connected devices can't benefit from CT. The initial claim you made was based on the unreliable connectivity and update channels of those devices, neither of which are especially implicated in enforcing CT --- your belief was that devices went and checked CT logs over the Internet on the fly to validate certificates, which, of course, no.
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.
It's not a completely nonsensical concern - Chrome relies on a reliable connection to Google in order to get log list updates and do SCT auditing. If an attacker can block log list updates for long enough, CT enforcement is disabled entirely (i.e. certificates with no SCTs will be accepted), and if they can block SCT auditing for long enough, bogus SCTs will not be detected. This fail-open behavior was an intentional design choice so that CT would never break the Internet, as DNSSEC so often has. I think CT made very sensible tradeoffs here, but I understand matthew9219's complaints even if the details aren't entirely correct.
I'm hung up on the idea that challenges keeping a log list updated disqualify CT, thus motivating deployment of DNSSEC, a protocol so dependent on a clean connection to the Internet that its deployment in browsers on modern operating systems was derailed.
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.
You are almost correct. The claims are called SCTs (precertificates are something else). The SCT is a promise by the log that they have (or will soon) publish the certificate. The promise could be lie. To detect that, the client is supposed to audit the SCT. If the audit fails, the client reports it so the log can be distrusted.
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.
I don't think you're providing clarity at all, because that attack doesn't work.
If you wanted to use your words to explain why you think that, that might be more constructive. I could well respond "yes, it does work" but that wouldn't be useful. I know you're an expert in the space and might appreciate learning from you, but this is not that.
I'm sorry, but I'm declining to do that, because I recognize the message board conversational pattern where all the information you have about the subject is coming from comments rebutting you (this is apparent from things you've said already that fundamentally misapprehend how CT works), and, rather than acknowledging any of that information, you just use it as vocabulary for new misapprehensions.
Clients do not get pre-certs. Those are generated by the CA, and submitted to the log in return for an SCT. Forging a ‘fake CT log’ isn’t possible, either. Nor do clients talk to CT logs, at all.
> Forging a ‘fake CT log’ isn’t possible, either
Why do you think this isn't possible?
Aside from what mjg59 said, it's clear you don't quite understand how CT works. Logs are stood up and then go through a fairly rigorous acceptance process by Google (and Apple) before finally being used. 'Used' in that a CA can then submit pre-certs to it and include the resulting SCTs in signed certificates, making them functional on Chrome/Apple platforms. Even the CA using the log generally takes some communication with the log operator to ensure the right set of roots are trusted for submitted pre-certs.
CT logs are used by CAs, not clients. A 'fake' log isn't a thing.
If you are able to compromise a CA and generate a bogus certificate, why couldn't you also compromise a certificate transparency log provider and generate a bogus signed merkle hash?
(Not that I'm a DNSSEC user myself, my feet aren't bulletproof)
Not sure what you really mean here - CAs are required to get SCTs from multiple, independently-operated logs. Even then, I think what you're implying here is mathematically impossible, and easily and immediately detectable. Bear in mind on at least 2 occasions these logs have detected and been decommissioned based on cosmic-ray induced bit-flips, not discovered by the actual log operators. CT is a pretty robust system.
Fwiw (tangent), I don't necessarily believe either of those instances were cosmic-ray induced bit-flips. I'd have to dig up the study, but I read a study once that more or less concluded "cosmic-rays are more common in memory unsafe languages and on overclocked PCs". Or more accurately, engineers frequently misattribute memory corrupt and operating outside specification to cosmic rays.
Particularly when the software in question is running on somebody else computer, proprietary software and OS (or OS modules), unknown patch versions, etc.
Because they don't have access to the private key material owned by the CT logs that the browsers trust when validating SCT data in the certificate.
I'm not sure why you're so fixated on this idea of client systems monitoring CT logs.
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.
In the attack DNSSec prevents, a client is compromised by a cert that doesn't appear in the CT logs, so infrastructure monitoring is irrelevant.
Most browsers will reject such a certificate. See https://googlechrome.github.io/CertificateTransparency/ct_po... for the policy Chrome imposes - my understanding is that Safari is broadly similar. Right now I don't think Firefox performs this validation, so this is possible if you know in advance that your target runs Firefox.
That page explains that Chrome (which is best in class here - most IOT devices don't do any of this stuff) fails open:
> 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?
You're moving the goalposts to a ridiculous degree. Chrome will be incredibly angry at you if you haven't updated in 70 days. How will a smart TV behave? I've no idea. It's probably not paying any attention to dnssec (otherwise pihole and co wouldn't work), so I don't think you're presenting a credible alternative.
That's just not what's happening. Reread the conversation. I started from here:
> 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.
Once you've got a 70 day old browser you're just waiting for it to hit one domain you can MITM or serve content from and then you've got arbitrary code execution and who cares whether dnssec is involved or not. Attacking CT is just not the threat model to be concerned about.
The example I gave was a router or gaming system updating itself (e.g. using CUrl) not a full browser. Don't strawman please - if my argument is as weak as you say, you shouldn't need to.
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.
The Play Store has cert pinning, so this all works just fine in the scenario you're describing.
Web PKI so strong that we recommend not using it for critical scenarios.. /s
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.
The whole premise of your argument about set-top boxes and CT was refuted, and you've used that as evidence that you were right all along.
Do you believe CT protects set-top boxes against surveillance from nation state actors who compromise your router? Yes or no, if you don't answer, you're not engaging in good faith.
Nobody's ever going to continue discussing things with you when you end your comments with barbs like "if you don't answer, you're not engaging in good faith."
I don't think firmware updates for routers is a good example. That seems more like the kind of situation where you should actually be using your own PKI.
Even if you trust the current CAs (all of them) to not intentionally issue bad certificates, you must also trust all of them not to have their systems broken into. If even one CA gets compromised, the hackers can issue certificates for any name.
How can you prove that all CAs log every certificate they produce?
You can't, but a certificate that isn't logged won't work for the overwhelming majority of practical use-cases (ie any Google or Apple owned product). If you need a certificate that doesn't care about those, you perhaps don't need a publicly-trusted certificate in the first place.
In addition to what nickf said in the parallel comment, CAs have committed to CT logging as part of being included in browser trust stores. If anyone were to find and report any certificates issued by those CAs via their trusted certificates that were not in CT logs, that would be strong evidence for browsers to remove them from the trust stores, which would essentially destroy their company.
That is not true. CAs are not required to log their certificates. Instead, Chrome and Safari by default do not accept certificates unless they are accompanied by a signed receipt from a recognized log. If you don't need your certificate to work in a default-configured Chrome or Safari there is no need for your certificate to be logged.
Source: I work in this space
Here what you really mean is "if your certificates will never touch Chrome", because it's not just that Chrome won't accept them, but that Chrome's SCT auditing is part of a surveillance system for certificate misissuance.
I'm not sure what you mean by "surveillance system for certificate misissuance". Chrome's SCT auditing has nothing to do with detecting certificate misissuance; just misbehaving logs.
I'm literally just waking up right now and typing this from bed (ignore what that says about me as a person) so cut me some slack if this makes no sense and I reserve the right to come back and "clarify" what I was saying but: if Chromes see a Sectigo certificate for (say) Facebook.com with no SCTs, Google is going to notice.
Nope. If Chrome sees a certificate with no SCTs, it rejects the certificate but doesn't report it to Google. (Except possibly for telemetry.) Google doesn't care if CAs issue certificates without SCTs; in fact, some CAs routinely do so for customers which want to keep internal hostnames private. (e.g. https://docs.aws.amazon.com/acm/latest/userguide/acm-bestpra...)
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.
Yep, I acknowledge this is the case. Thanks for the correction!
The alternative is secure and decentralized DNS like 'unstoppable domains", DNSSec is too clunky and centralized to help here.
Let's say the US wanted to perform an attack that DNSSEC would have prevented, what does that attack look like?
The US seizes the cryptographic material for a US based root, issues keys and certificates for the domains it wants to compromise and intercepts and modifies the traffic for targeted users. There's some additional asterisks around not getting caught and certificate transparency logs and browser reporting structure, but for many classes of devices, it will suffice to simply also hijack the domains used for requesting the transparency log or the domains used for reporting certificates that don't appear in the log.
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.
If the US is going to seize cryptographic material from CAs, they've probably got no problem ordering US based domain registries to do their bidding either. If it's Verisign registry, they can use the Verisign CA too, and it's only one company to compel.
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.
First off, ICANN doesn't run the root servers. ICANN operates 1 root server identity,l-root.root-servers.net. The others are run by different organizations.
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!
> 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.
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?
Admittedly, the US is a bit of a special case because of ICANN. Better examples are probably Saudi Arabia, Israel, Australia, Russia, etc.
For a state like the US, with it's laws and history on surveillance. I assume PKI has been compromised.
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.
> I don't check or audit my CA's and don't think most people do either.
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.
Everybody has to do business somewhere. Nobody can prevent the government in whose territory they do business from compromising them. The question is whether you can be compromised by all governments (TLS) or just your government (TLS+DNSSec).
> 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
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.
Every single certificate issued by a WebPKI CA (ie: a CA whose certificates are accepted by Google or Mozilla's root programs) is logged in a globally auditable tamper-proof log. You can stand up an instance of that log, or monitor any of the existing logs yourself. You're not relying on laws to surveil the WebPKI CAs, but rather mathematics.
A log to secure TLS which clients typically obtain over a TLS connection and whose violations they report over a TLS connection. It's a circular dependency.
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.
This isn't how CT is used in the real world. It's not like OCSP.
DNSSEC is easily the worst upgrade, multiplying complexity and brittleness, with the least amount of net benefit (without even adding encryption), that could have been solved in much simpler ways, that the Internet has ever attempted -- and that's including IPv6 (which is now quite workable).
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). ¯\_(ツ)_/¯
At this point it feels like DNS should be given to Cloudflare or Google and let them design it from scratch.
I'm only half joking.
I'm not real enthused about Google doing standards. OAuth/OAuth2 are both so half-baked that we now have OIDC built atop them to try and make it look like a consistent workable standard.
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.
"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."
What else would we expect from an advertising company.
Or both.
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.
For sure. DNS is definitely something that should either be canned after 2 years, or protected by 50 captchas.
What we would get is some Google/Cloudflare protocol which “incidentally” centralizes everything to them, not to any TLD operators (i.e. governments) or user agents.
Been there, done that, albeit on a smaller scale. And I don't envy the people running the .nz registry at all, and they have my best wishes.
I hope the situation gets resolved swiftly, and lessons learned from this incident can contribute to stronger and more reliable DNSSEC practices in the future.
The root KSK rollover had to be postponed twice, for several years, because of operational problems pulling this off in the US. It's difficult to do because the nature of the DNS makes it difficult. The utility of DNSSEC is so marginal that it's kind of sad that you're right, and that engineers are gradually getting better doing this hard, stupid thing.
You're not learning if you're not failing, so failing is good actually.
I think the pithy saying is that we learn best from failure, not that there is no other way to learn.
Yep: "don't deploy DNSSEC, rely on TLS"
TLS security is rooted in DNS. It's ACME DNS-01. If your threat model includes nation states, this is a non-solution
Wrong, TLS security is independent from DNS. If my threat model includes nation states I'll trust my own certificates or my very own CA.
By trusting certificates, you implicitly trust all CAs, not just your own.
You trust your browser's root program, not "all CAs".
That’s what a “CA” is. If someone is not in a browser’s CA list, they’re not a CA. So yes, you do trust all CAs.
That’s not all what CA means in standard usage. Terms like WebPKI exist specifically to make that distinction since, for example, the U.S. government runs its own certificate authorities which are trusted by millions of clients and even some mainstream software (Adobe) but not browsers. This is far from unique as far as governments go, and in some cases may even be required within a country.
Those non-web CAs are not the topic of discussion, though. When we are discussing the DNSSEC PKI, we are not discussing any altroots¹. When people are discussing the CA system for TLS, they overwhelmingly mean the normal web CAs.
"The normal web CAs" means "the Mozilla and Chrome root programs". There are other CAs, and some of them are even in the root stores of other browsers, but they're not "trusted" in the sense you meant upthread.
No, obviously, different TLS programs have different root programs.
No, again in that threat model I can decide exactly which certificates and which CA I trust, one by one.
If your threat includes nation states then DNSSEC is double-useless?
If your threat model includes nation-states then DNSSEC won't help you either. WebPKI at least has a method for keeping track of and detecting misissuance, DNSSEC doesn't.
If a safety upgrade to driving a car made people crash their cars more, you'd call that a bug. For DNS it's a feature called DNSSEC.
Some car automatically lock their doors during driving in order to prevent hijackings, especially at red lights.
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.
> or is the solution to fix the problem of the car doors staying locked when submerged into water?
The natural progression is for hijackers to then carry buckets of water or spray cans and target the sensors that detect a water scenario.
Seems simple: we should abandon these particular car door locks, but not necessarily the concept of car door locks altogether.
If we follow this analogy further, why should we keep the concept of car doors if particular car locks can be made with bugs in them? Doesn't the possibility of bugs in locks means that there will always be a risk, even if we abandon specific locks that has demonstrated to have a bug in them?
We should keep the locks that work and don't cause other problems, and ditch the other ones. Again, seems simple.
Depends whether locks can be made to work.
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.
Locked doors can help prevent the door from flying open in an accident, too.
And maybe make rescue more difficult after a crash?
Doors are part of the structure of the vehicle and must stay closed to do their job in a collision. To my understanding this is the primary if not sole reason doors lock after a few seconds in motion.
Not much more difficult. In case of a crash first responders break the window and unlock the door.
I'm not really a fan of dnssec, but in fairness to the analogy - car keys really do make life harder if you need to rush someone to the hospital and dont have the keys.
Your analogy would only be valid for a bug that made impersonating a site easier somehow, which this one didn't.
Fortunately, New Zealanders benefit from all of the problems solved by DNSSEC.
Isn't DNSSEC basically obsoleted by DoH?
In a sense, yes, but not so much so that DoH is a dispositive argument for deprecating it.
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.
I think the best argument for DoH being the killing blow to DNSSEC is that not only does DoH overlap a lot with the security features DNSSEC is trying to be the solution for, but DoH also gives you arguably more important security features that DNSSEC does not and cannot reasonably provide.
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.
> DoH has massively better deployment stats than DNSSEC, so this is plausible
Is this actually true where it matters? (i.e. the root servers and authoritative servers for TLDs)?
Where what matters? On-path DNS attacks occur everywhere across the Internet, and are probably more common on the lookup side and at the edges. Certainly, the use of DoH to protect authority transactions isn't common, yet!
The most devastating and primary attack I am worried about is someone obtaining a TLS certificate for my domain via services like Let's Encrypt.
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.
LetEncrypt does validate DNSSEC signatures (when they exist), but CA's aren't even required to do that. LetsEncrypt also does multi-perspective lookups, so a single hijacked DNS transaction or poisoned cache is insufficient to trick it. Hopefully, at some point in the not-too-distant future, LE's multi-perspective lookup will generate data we can look at about the frequency of DNS attacks on certificate issuance. I expect it to be quite rare, because it's an elaborate attack with a weak payoff.
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'll take this massive shift of the goalposts as agreement that DNSSEC is much closer to solving some problems today than DoH is.
I would appreciate it if you would update your other comments in this thread clarifying that, as we both now agree they are incorrect.
Subscribe to CT logs for your domain, and you will know if this ever happens, from LE or from any oher authority. Such attack is a very big deal, if this happens this will only happen once, whichever hole is used will be closed. And if this does not happen, you can be rest assured your TLS is safe.
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".
> 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.
I think you misunderstood the claim: say the U.S. government leaned on the .com DNS server operators to issue a different response for, say, Gmail.com to certain requesting IPs. The absence of a mechanism like CT makes that very hard to detect since everyone else in the world is going to see the same correct response, and there’s no reason for the target’s DNS resolver to question a response with a valid DNSSEC signature, and since DNSSEC has no UI there’s not even a way for the user to notice.
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.
They serve different purposes. DoH protects DNS information while in flight. DNSSEC cryptographicly signs DNS records so they can be validated as being created by the owner of the domain. With only DoH you can be assured of privacy in flight and that the response hasn't been changed in flight; however, you don't know that the records on the server you connected to have not been manipulated.
The motivating use case for "cryptographically signing DNS records so they can be validated as being created by the owner of the domain" was the protection of those records in flight, which is something DoH does.
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.
> The motivating use case for "cryptographically signing DNS records so they can be validated as being created by the owner of the domain" was the protection of those records in flight, which is something DoH does.
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.
Nice quote. I don't understand why so many people on HN have such a vocal dislike of DNSSEC and DoT. It's perfectly ok for DNSSEC, DoT and DoH to co-exist.
Let’s say I operate my own authoritative DNS servers and my own web server. Which I do.
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?
> 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.
No. They're completely unrelated. DoH/DoT are solutions for encrypting the traffic to hide it from ISP, they do nothing to improve trust in the results (unless you trust the resolver and the CA they used to sign, but then that's the same world you were already in with TLS after the fact).
In the same way that TCP is obsoleted by WebSockets. Personally I'd prefer a solution which is neither of them.
Maybe the cars crash more, but at least they won't take any wrong turn.
if your browser ignored all certificate errors, I guess you'd call that a feature?
If your browser ignored all certificate errors, you'd have a real security problem. That's not at all the case for DNSSEC: it's possible that all of the DNSSEC root keys could hit Pastebin and nobody would really need to be paged.
Browsers did ignore most certificate errors back in the early 2000s. HTTPS sites were fairly rare and most people did not care about it or even considered https to be a negative. Many administrators considered it as bad technology that only increased instability with no obvious benefit. "Who cares about what people post to a forum?" was something I personally heard when I added https to one site. It was only really banks with plain passwords that needed https, and then external hardware devices really made https obsolete for that problem.
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.
> Browsers did ignore most certificate errors back in the early 2000s. HTTPS sites were fairly rare and most people did not care about it or even considered https to be a negative. Many administrators considered it as bad technology that only increased instability with no obvious benefit.
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.
I recall well those discussions. Web stores did indeed often use https to protect credit cards. The argument was however that physical stores did not need to have similar protection, and that the issue really was with the weak security of credit cards. HTTPS was a unstable solution for a problem which people argued should had been solved with the credit card system. Physical security devices was again lifted as the future solutions to this problem.
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.
Old certification invalid dialog was terrible. I believe most people just ignored it. https://cdn.appuals.com/wp-content/uploads/2018/11/identity-...
Yes, that’s why I found the assertion that it didn’t exist so odd since almost anyone who supported web sites or browsers back then was familiar with that dialog.
Links:
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:
So many outages. About one every other month affecting country TLDs.
What the real problem probably is, is that all this is still being done by hand. It should be automated, and there is some work being done in that area: <https://github.com/DNSSEC-Provisioning/music>
Why can't I read this in reader-mode?
Supplementary question: Why do so many sites these days opt for tiny font-sizes in some shade of pale-grey on white?
Fortunately, I was spared from witnessing any swamping in this DNSSEC, and all credit goes to onenz for instigating positive transformation.
Economic impact of no-dns-resolutio.nz?