Recent submissions

Comment · 9 days ago
Anything that doesn't eliminate the current model of "a whole pile of CAs of unknown and widely-varying reliability are ultimately-trusted by every TLS client in the world despite the numerous times that has caused serious problems for approximately everyone on the Internet" is IMHO not significantly better than what we have now. The trust is the problem, and shorter certificate lifetimes or restrictions on usage flags or the various other things trying to work around that issue don't solve it no matter how many of them are implemented -- they're bandaids on a shotgun wound.

But let's whiteboard for a bit: if you agree (as I assume you do) that the current situation is at least more insecure than it should be, and should ideally change fundamentally, and if you don't think DANE is the right fundamental change, what would you implement instead if you had the magic wand to make everyone agree to do it?

Comment · 9 days ago
Not lose control exactly. But if ICANN is willing to, they have the power to simply make that control irrelevant in any specific case. The government in question would have absolute control of a TLD registry that no one else considers authoritative for that TLD. If you're a hermit kingdom like North Korea anyway, that's probably not a big deal, but for anybody else it's liable to be a very big deal indeed.

I would expect ICANN to use that power very sparingly, preferring to publicize rather than act as a first step, and if they did get heavy-handed, again they would incur a hit to their legitimacy.

The only reason it's considered unthinkable that could happen to .com is that everybody agrees it's unthinkable to do that to .com. But ICANN absolutely could make a credible threat to US control of .com or .us if they felt it warranted to do so. (You could say they're ICANN, not ICANN'T.) They could do the same to .gov, for that matter, but the US government already explicitly owns and controls that whole hierarchy, so there's no real "interference" issue there.

The whole Internet's viability is based to some extent on the collective delusion that everybody agreeing this is how it works, actually makes it how it works. But none of that is set in stone... which is generally a good thing.

Comment · 9 days ago
Honestly even if they were issuing certificates for much longer than they were supposed to, that is a way lower level of risk than "everybody in the world absolute-trusted a CA certificate that turned out to have a 256-bit private key crackable in seconds".
Comment · 10 days ago
I'm not sure (but would love to know) if Sectigo actively chose to sign eMudhra's certs (though if eMudhra is a reseller of theirs, it would make sense to do so), or if maybe it was just "their turn in the barrel" to be the designated cross-signer of a new CA's certs so the new CA could be a useful entity.
Comment · 10 days ago
Comment · 10 days ago
So the answer is just to use only the weaker option forever?
Comment · 10 days ago
You don't think so? In a scenario where it becomes known the US government is actively subverting Verisign to tamper with DNSSEC integrity (or where Verisign just screwed up badly enough to make their continued stewardship untenable, and I think either case would become known, in pretty short order), I absolutely think ICANN would expatriate .com. If they didn't, they would lose legitimacy with everybody who isn't the US government. That leads to at best an international effort to replace ICANN and at worst the splintering of the DNS root. Nobody wants either of those scenarios -- the least-damaging thing for the Internet and for ICANN as an organization would indeed to be to take .com away and let say, the British run it for awhile. (Maybe you could get your .com domain registrations at Sainsbury's, in the aisle next to the anti-demon plant misters.)

Which is exactly the kind of scenario a lot of people hyperventilated about back when ICANN was formed, for reasons of varying validity, but in this case it would indeed be the least-worst option all around.

Comment · 10 days ago
See my other comment above. A malicious TLD operator is not something everyone is just powerless to deal with.
Comment · 10 days ago
I don't think (and wouldn't hope) this would be a flag-day thing where we stop using CA trust completely all at once and only use DANE afterward. DANE would become an option, disabled or secondary by default, that users could choose to use as a fallback if CA-based TLS validation fails. Eventually as adoption increased and the critical paths got cleaned up, DANE could become the default primary, with a fallback to CA trust if there's no valid response to a TLSA record request. Eventually as CA trust fell completely out of favor for most uses, it wouldn't be necessary for many clients to support it at all.
Comment · 10 days ago
Comment · 10 days ago
It seems much less likely that even a well-funded state actor could silently subvert enough root servers, which exist in many countries, to significantly compromise DNSSEC before alarms were raised, than that CAs are actively compromised or are just bad at being CAs, resulting in a breach like this (which happens approximately all the time). And with regard to state coercion, some CAs are in fact state-run, by states most people would consider grievously corrupt.

More to the point I would trust IANA and ICANN, faults and all, to not screw up the DNS/DNSSEC root, much more than I trust every CA in the default browser trust stores to get X.509 right all day, every day.

Comment · 10 days ago
The big takeaway here is: Web PKI is fundamentally broken, and the existence of CAs as a concept is the vulnerability that must be fixed -- or, more specifically, the idea that ultimately trusting a relatively small, basically fixed/hard-to-change set of (mostly) commercial entities with something this critical and far-reaching is (or ever was) actually a good idea.

There are a lot of reassuring statements from browser makers and others about how their mitigations for exactly this scenario kicked in and protected (some set of) Internet users, but IMHO there is not nearly enough discussion happening about fixing things so those mitigations are not needed to begin with.

Comment · 10 days ago
eMudhra was a root CA. Their roots and intermediates were cross-signed by Sectigo since it was a new(-ish) root CA (a comment on Reddit characterized eMudhra as a Sectigo reseller, but I can't find verification of that), but I don't know to what extent that was done as a result of Sectigo's own evaluation vs. some internal process of a larger entity like the CA/Browser Forum. (Without cross-signing, it's difficult for a new CA to operate, so I imagine there must be some process by which a particular existing-CA cat is belled to be the cross-signer.)
Comment · 10 days ago
This all day. There is no reason I should have to go through a third-party to get a certificate just to distribute a key for secure communications (which is all a DV certificate is good for) if I already own a domain, or can get the domain owner to publish my TLSA record in theirs (which should be no more onerous than publishing the server A record, which they already have to do).

The reason we don't have DANE support in browsers is of course because Google decided not to implement it in Chrome, because (ultimately) the key lengths securing the root DNS server zones weren't large enough to suit them (at the time, 1024 bits):

https://www.imperialviolet.org/2015/01/17/notdane.html

And if Google wasn't going to do it, it didn't make sense for any other browser to do it either.

However, I believe the root zone keys are now longer, so I could (potentially) see Google implementing DANE in Chrome now, maybe with a Chrome-specific restriction of "TLSA records that have keys under 2048 bits in their chain of trust are ignored" (since the root zone keys are not the only keys in the chain and they want to eliminate 1024-bit RSA from Chrome). And if Google does it in Chrome, then everybody else has to do it too, so the situation flips.

Comment · 4 months ago
> LLMs aren't mapping applications, they're reasoners.

No they aren't. They're statistical token generators. They do not understand concepts such as "distance from a given location or coordinate point". If you're lucky you might ask it something likely to appear nearly verbatim in its training data, like "Chinese restaurants in Midtown Manhattan", and get back a reasonably accurate list, but it does not understand what a "Chinese restaurant" is, or what "Midtown Manhattan" is, or that one relates to the other in any way other than both appearing statistically associated with another set of tokens when they appear near each other.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton