mwwaters

A sufficiently sandboxed, low-stakes thing that self-verifies by its visual output can be easily created by AI.

For security or applying business logic (and how it interfaces with programming or database logic), you get less and less assurance by just looking at it.

It would need to be through TLDs all reporting new DANE records, or DANE itself would need to change.

The threat model here is the TLD was somehow unknowingly hacked and the bad DNS records are somehow not noticed. Or worse, the body governing TLD is in on it. In these cases, only the users of the websites are in a position to report on the bad certs. Each website could try to monitor the DNS records similar to CT logs, though for targeted attacks that may not work.

Again, I don’t get this argument. A compromised TLD absolutely kills any validation (other than EV) already. An A/AAAA can be posted for page validation or TXT for DNS validation.

As far as I know, no TLD operator has gotten the death penalty. It is technically possible for root to change the IP addresses, but it would be bound up in whatever the governance is of the domains.

But the downside isn’t something new that would just apply to a DANE world. That downside still exists in the CA world. The CA is just an additional point of failure, along with the TLD.

What is added by the CA world is CT.

I meant that for a compromised TLD key, the DS record at root lasts for a day. So I didn’t follow how the compromise in a theoretical DANE-only world would be inherently long-lasting.

You said “no recourse,” which I took to mean no recourse even if known. I don’t follow that. The key/DS record at root can be changed. There may not be a “TLD death penalty,” but the key could be changed.

Now without CT it may be tougher to know about the compromise. For websites that don’t have the luxury of certificate pinning, a compromise of TLD kills the whole thing, at least for a time.

Low TTLs aren’t incompatible with the ideal of using DNSSEC though? From what I can tell DS records typically have TTL of 1 day in the root domain.

What is a difference, versus DANE, is that TLS uses CT. Compromised TLDs happened recently but was found out through CT. A compromised TLD still kills the whole system for a time regardless.

I think DNSSEC still has some use in enforcing email TLS and for CAs.

I liked the idea conceptually of CAA record only allowing DNS validation. Then use DNSSEC.

I say “conceptually” since I know: 1. Actual attacks found with CT have used compromised TLDs, which kills the whole thing anyway, and 2. I haven’t really seen where the hosting company’s infrastructure (BGP ads and internal routing) is what’s compromised. Well certainly in the latter case they can probably also get in to the hosting machines directly.

Which userspace API was changed?

Internal Kernel API changes all the time which can break proprietary drivers. But userspace API has a far higher guarantee.

I know this is true. But I don’t think “Some parts of important codebases are black boxes. Therefore it’s fine if all of that code base becomes a far bigger black box” sounds like a good argument.

Also, there was probably some human at some point that had some understanding of what they were trying to do and why. The black boxes generally get programmed around after they long left but at the time they had bugs ironed out over decades. (Yes I know sometimes true slop is done over a short period of time and the programmer leaves. But I’ve generally seen the black box built over decades instead).

The Windows 11 ISO on a two year old Lenovo laptop did not have the Ethernet or WiFi driver. “Have Disk” also did not work for whatever reason when I downloaded the driver to a USB drive. I had to open up a command prompt within the Windows installer and run the GUI driver installer.

In Linux, I now have a custom Arch install which Gemini did help with a lot. It helped unblock significantly where I wanted to get fundamental understanding. A Debian installer will just work though (ironically, some years ago, I had issues with Ubuntu working out of the box but not Debian).

The passkey method uses Bluetooth to ensure proximity.

The far bigger benefit is phishing resistance (with hardware-contained keys themselves being phishing-proof on a non-compromised system).

It moves to the account recovery flows, but that can be much more difficult to phish.

The first FRED link shows how noisy that subgroup is. It’s bounced around with 83-84% during that time. It was 83.8% in March and 83.5% through much of 2024.