Interests of the existing PKI industry may be the source of some friction, but the bigger issue is that DANE depends on DNSSEC, which is not widely deployed, and sometimes actively avoided due to its complexity and ease of breaking you site.
Don't get me wrong, I'd love it if DANE, or something similar caught on, but I don't think it is practical until something changes to make DNSSEC (or equivalent) common.
> 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.
It's funny to see that the issues with X.509 certificates, are being solved by what X.509 was intended to be used for: a directory system. It's DNS instead of X.500, but it's a start.
One quibble with the article: the notion that CRLs have to be large. When I was with Entrust our first releases targeted early Windows versions with limited memory, back when most Internet connections and even local networks were slow.
To ensure that RLs would always be manageable in size, we used distribution points (cRL and issuing) and decided at certificate issuance which RL would contain this certificate's serial number if ever it were revoked.
This approach scaled really well and kept RLs manageable.
There were applications that didn’t understand distribution points and needed the One RL to Revoke Them All, so we supported that as well (as an option, IIRC).
7 comments
[ 4.1 ms ] story [ 19.4 ms ] threadInterests of the existing PKI industry may be the source of some friction, but the bigger issue is that DANE depends on DNSSEC, which is not widely deployed, and sometimes actively avoided due to its complexity and ease of breaking you site.
Don't get me wrong, I'd love it if DANE, or something similar caught on, but I don't think it is practical until something changes to make DNSSEC (or equivalent) common.
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.
To ensure that RLs would always be manageable in size, we used distribution points (cRL and issuing) and decided at certificate issuance which RL would contain this certificate's serial number if ever it were revoked.
This approach scaled really well and kept RLs manageable.
There were applications that didn’t understand distribution points and needed the One RL to Revoke Them All, so we supported that as well (as an option, IIRC).