I don't know of any other monitors that gossip (except for 's defunct monitor), but it's not hard, esp compared to SCT auditing! IMO, ensuring that monitors and browser vendors see the same view of logs is a solved problem, with a de facto spec and running code.
Conversation
It's still a reactive rather than preventative mechanism and most organizations don't and won't have any monitoring of CT logs. It only works for organizations like Google that are going to track all their valid certificates and monitor the logs to check for any invalid ones.
1
1
It's still only able to catch something after the fact. That doesn't do much good when it's so hard to remove a CA. It's an incredibly broken system, and WebPKI relies on DNS secure regardless. There's nothing meaningful beyond DV which is based on DNS security anyway.
1
TLSA records (DANE) + DNSSEC work well. They remove CAs as trusted parties without adding a new one. It's being heavily adopted for non-Gmail SMTP federation already. Microsoft is adopting it for their mail services. Google is adopting an insecure mechanism (MTA-STS) instead.
1
1
2
MTA-STS doesn't even provide WebPKI level security. It only provides comparable security to only using http:// URLs with dynamic HSTS, no HSTS preloading and no Certificate Transparency. It works well for web sites too but browsers have chosen not to provide security to users.
1
Significant number of client side networks and resolvers have compat issues with DNSSEC. DNS-over-TLS / DNS-over-HTTPS resolve this when they're in active use. There's no technical reason Chrome can't do DNSSEC + TLSA record validation when using DoT/DoH. Why not even mention it?
1
1
The past reasoning for the path taken by Chrome no longer holds up. I'd like to hear why DNSSEC+DANE is good enough for Microsoft but not for Google. I'd like to see Google employees not go out of the way to avoid acknowledging it exists and give reasoning for stuff like MTA-STS.
1
1
It's not true that only organizations "like Google" monitor logs. Organizations big and small use Cert Spotter (both the open source and commercial version) or other tools to monitor CT. Meanwhile, there is no way to detect if a malicious registry signs unwanted TLSA records.
2
Browsers switching to DANE would be a major step backwards in transparency, which has in fact led to bad CAs being distrusted (WoSign, Symantec, Certionomis, Camerfirma, ...). Yeah, MTA-STS sucks but this is way off-topic from the blog post.
1
Replying to
DANE isn't a step backwards for transparency. Enforcing TLSA records does not require dropping WebPKI + CT as requirements for certificates to be considered valid. DANE can be used for pinning rather than fully replacing WebPKI. It's not a choice between security or transparency.
1
1
I'm saying that Chrome should be enforcing DNSSEC + DANE when using DoT/DoH. I'm not saying that they replace the existing requirements with a different approach but that they should support pinning via DNSSEC + DANE to allow sites to stop trusting CAs for users with DoT/DoH.
Many DANE advocates do want it to be available as a full replacement for WebPKI. I'm not suggesting that Chrome should do that. It's usable as either a full replacement or a pinning mechanism. I know Chrome isn't going to drop CT and I'm not proposing that it should be doing it.
2
It would be 100% possible to develop a transparency mechanism not requiring WebPKI CAs to be involved, but that isn't a requirement for using DNSSEC + DANE + CT. WebPKI is perfectly compatible with DANE. Look at mail.grapheneos.org or GrapheneOS web sites. They all use both.
1
Show replies