[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.