> With this approach, they have shown a reduction in CRL data from a list of all enrolled and unexpired certificate serial numbers from 6.7G to a filter of just 1.3 MB.
It actually gets even better: Mozilla's CRLite deltas with generation on a 6-hour interval are only about 60kB! Even with 10 billion internet devices fetching every 6 hours you're looking at a mere 222Gbps of bandwidth: a lot, but plenty of tech companies do more.
> At this point, why not just use DANE (RFC 6698), store the public keys in the DNS, rely on DNSSEC to provide the necessary authenticity, and use DNS TTL settings to control the cached lifetime of the public key? With a combination of DNSSEC Chain Extensions and DNSSEC stapling, it is possible to perform a security association handshake by having the server provide the client with (...)
Yeah, until an attacker gets access to DNS, stores a record with a TTL of 1 year, and staples that - of course after poisoning the caches of major DNS resolvers with the address of the attacker's server.
> until an attacker gets access to DNS, stores a record with a TTL of 1 year,
DNSSEC may have problems, but that's not how the trust model works. Also signing is separate from authoritative DNS, so you'd need to compromise the signing itself, not just DNS. Should that happen, you are still limited by the upstream record siganture lifetime.
On the other front (Chrome), their crlset-tools [1] just fetched me 64k (~1.1MiB) of revoked certs just fine, contrary to the article (quote: "After retrieving and running this tool, I was surprised to see a total of 1,081 revoked certificate serial numbers in this list. This seems oddly low.")
[1] https://github.com/agl/crlset-tools