Hacker News new | ask | show | jobs
by mjg59 1112 days ago
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.
1 comments

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.