indolering

For a definition of "efficient" that isn't shared by anyone else. This isn't a new rationale either, but a well known trade-off involved with JIT compilation and garbage collection. It's the reason Chrome "hogs" memory and Firefox is perceived as slow: they make different resource usage tradeoffs.

It will be interesting to see if the current memory crunch will impact this calculus going forward.

Montenegro (.me) seems to be aligned with the EU. But I would have expected there to see a legal ruling in France before Montenegro would do this sort of thing.

I wouldn't be surprised if GoDaddy caved to request. They are known for giving up domains to anyone with a badge and a fax machine!

That's not how I remember it: it was an experiment that was useful at the time but didn't work out. It was useful internally to sandbox Flash player, but the limitations of the LLVM based approach were soon evident to everyone involved.

I really wish I had messed with Windows Phone when it was a thing. They were the only ones not to just ship a clone of an existing interface ASAP. But it was closed source and offered no advantages for carriers or device makers compared to Android.

WebOS needed WASM and a lot more to be successful. I think WASM/WASI is to the point that the next major platform build out can use it.

The floating point "standard" was basically codifying multiple different vendor implementations of the same idea. Hence the mess that floating point is not consistent across implementations.

The answer is unequivocally yes: RISC-V is designed to be customizable and a vendor can put whatever they like into a given CPU. That being said, profiles and platform specs are designed to limit fragmentation. The modular design and core essential ISA also makes fat binaries much more straight-forward to implement than other ISAs.

I think it's a joke: you REALLY don't want to own your own servers.

I'm not unaware of this and I agree that WebPKI has greatly reduced global risk. New DNS tech takes a lot longer to implement but that doesn't mean we should kill DNSSEC support like the trolls insist upon!

Why would Let's Encrypt not also be interested in safeguarding DNS, SSH, BGP, and all the others? Those middle boxes will have to get replaced someday and we could push for regulation requiring that their replacements support DNSSEC. These long-term societal investments are worth making and it would enable decentralized DNS.

I'm also concerned that none of this will happen if haters won't stop screaming, "DNSSEC doesn't do anything but ackchyually harms security!".

(@tptacek: please stay out of this comment thread)

> The same reasons not to deploy DNSSEC that face large organizations apply to you: any mistake managing your DNSSEC configuration will take your domain off the Internet (in fact, you'll probably have a harder time recovering than large orgs, who can get Google and Cloudflare on the phone).

Set your TTL to five minutes and/or hand over DNS management to a service provider.

> Meanwhile, you get none of the theoretical upside, which in 2026 comes down to making it harder for an on-path attacker to MITM other readers of your site by tricking a CA into misissuing a DCV certificate for you --- an attack that has already gotten significantly harder over the last year due to multiperspective. The reason you don't get this upside is that nobody is going to run this attack on you.

Didn't save Cloudflare from a bad TLS certificate being issued. I still think that reducing the number of bad actors from 300 to the root servers and your registrar is a meaningful reduction in attack surface.

> DNSSEC attempts to address just a subset of these; most especially MITM attacks, for which there are a huge variety of vectors, only one of which is contemplated by DNSSEC.

How would authenticating DNS records cryptographically not address cache poisoning, MITM, and DNS spoofing in relation to DNS lookups? Also, DNSSEC doesn't have to solve all problems to make it worth doing.

> Finally, I have to tediously remind you: when you're counting signed domains, it's important to keep in mind that not all zones are equally meaningful. Especially in Europe, plenty of one-off unused domains are signed, because registrars enable it automatically. The figure of merit is how many important zones are signed. Use whichever metric you like, and run in through a bash loop around `dig ds +short`. You'll find it's a low single-digit percentage.

Yet you complain about DNSSEC being to hard to deploy and not getting enough deployment. Wouldn't it be nice if they could leverage that automatic signing to also generate TLS, SSH, and other certificates?

It can be used alongside WebPKI. And as someone who is worried about other protocols, it sure would be nice if I could setup DNSSEC for my domain and have clients pick up on that automatically.

More rhetorical dunking instead of engaging with the substantive technical issues. I'm done.

But it also applies to every other part of the stack, including WebPKI. Would you accept this as a valid argument against using HTTPS everywhere?

DNSSEC also solves a bunch of real world threat models that do cause massive security issues. I think we should put that effort into DNS as well.

That's fair! My primary gripe was about the need for non-profits to step in to begin with. Sorry if I didn't communicate that well.

However, I'm don't feel sorry for registrars or TLDs. Verisign selling HTTPS certs while running the root TLDs is a conflict of interest and I believe the perverse incentives are a big part of the reason why DNSSEC and DANE are stalled out. TLDs are a monopoly business and ICANN is quasi-commercial entity that should never have been a for-profit business.

I certainly think it is fair to ask them to pay for all this.

I would really appreciate it if you would respond to my points instead of just moving on to another argument.

Do you hardcode Github and AWS keys in your SSH config? Do you think it would be beneficial to global security if that happened automatically?

DNS is where domain name authority is delegated. Anything you build on top of that is also going to be a world of hurt if it gets compromised.

DNSSEC PKI does not preclude one from hardcoding specific keys in the client as well.

Providing global PKI and enabling end-to-end authentication by default for all clients and protocols certainly would make the internet a safer place.

Phishing existing isn't a good argument against cryptographically authenticating DNS records.

The engineering effort! ECC solves the theoretical concerns around latency anyway yet we have people arguing that it shouldn't be done. But if it was worth making HTTPS faster to secure HTTP, why not DNS?

If DNS PKI is compromised, so is HTTPS. So yes, they would be scrambling too.

HTTPS also has expiring keys that also need to be rotated. Most people outsource this to a service provider for them - as is the case with DNS. It's weird how people gripe about standard cryptography/PKI when it comes to DNSSEC but not HTTPS.

And for everyone else that just wants to connect to an SSH session without having to setup PKI themselves? Tying that to the records used to find the domain seems like the obvious place to put that information to me!

DNSSEC lets you delegate a subtree in the namespace to a given public key. You can hardcode your DNSSEC signing key for clients too.

Don't get me started on how badly VPN PKI is handled....

> None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case.

It would benefit the likes of Wikileaks. You could do all the crypto in your basement with an HSM without involving anyone else.

> That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.

But do they? That requires adding support for another protocol.

I would like to live in a world where I don't have to copy/paste SSH keys from an AWS console just to have the piece-of-mind that my SSH connection hasn't been hijacked.

> LE isn't primarily funded by non-profits, as you can see from the sponsor list here: https://isrg.org/sponsors/

I mean, Mozilla got the ball rolling and it's still run on donations (even if they come from private actors).

> Like I said, it may be cheaper in aggregate, but I think you'd need to make that case.

The PKI is already there: we have 7 people who can do a multisig for new root keys. There is a signing ceremony in a secure bunker somewhere that gets live streamed. The HSMs and servers are already paid for. Cert transparency/monitoring is nice but now it's hard-coded to HTTPS instead of being done more generically. There's a lot of duplicated effort.

> They did, and then we spent an enormous amount of time to shave off a few round trip times in TLS 1.3 and QUIC.

But if it's worth doing for HTTP, why not for DNS?

> Actually, it really depends. It can actually be faster. Here are Mozilla's numbers from when we first rolled out DoH.

Oh fun!

Which is a problem with the OS and browser, not with DNSSEC.

DNS underlies domain authority and the validity of every connection to every domain name ultimately traces back to DNS records. The amount of infra needed to shore up HTTPS is huge and thus SSH and other protocols rely on trust-on-first-use (unless you manually hard-code public keys yourself - which doesn't happen). DNS offers a standard, delegable PKI that is available to all clients regardless of the transport protocol.

With DNSSEC, a host with control over a domain's DNS records could use that to issue verifiable public keys without having to contact a third party.

I ran into this while working on decentralized web technologies and building a parallel to WebPKI just wasn't feasible. Whereas we could totally feed clients DNSSEC validated certs, but it wasn't supported.

It's a lot like HTTP and every other early internet protocol that existed before the crypto. Everyone agrees that it's a problem but fixing all the existing infra is really hard and expensive.

> Sir, this is a Wendy's.

This you?

Sorry, the point I was trying to make is that this isn't a problem operationally.

Hyperscalers go to crazy lengths because they can measure monetary losses due to milliseconds of less view time and it's much easier when they have distributed cloud infrastructure anyway. But it's not really solving a problem for their customers. At least when I worked in DNS land ... latency micro-benchmarking was something of a joke. Like, sure, you can shave off a few tens of milliseconds, but it's super expensive. If you want to reduce latency, just up your TTL times and/or enable pre-fetching.

As a blocker for DNSSEC ... people made arguments about HTTPS overhead back in the day too. DoH also introduces latency, yet people aren't worried about that being a deal killer.