[tptacek]

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.

[matthew9219]

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.

[tptacek]

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.

[agwa]

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.

[tptacek]

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.