3 ms·
You could store the certificate hashes in DNS (i.e., use DANE instead of the CA PKI) and so a MITM on the actual connection wouldn't succeed.
by cyphar 1y ago
You could store the certificate hashes in DNS (i.e., use DANE instead of the CA PKI) and so a MITM on the actual connection wouldn't succeed.
- cortesoft 1y agoRight, but what if the certificate is compromised? How would your revoke it?
- cyphar 1y agoIf the DNS entries for the certificates have a very short TTLs (i.e., 2 minutes) then you wouldn't need explicit revocation infrastructure. It would probably take more than 2 minutes for CRLs or OSCP changes to propagate anyway. (I'm not necessarily in favour of this, I just don't see the revocation part as being the main issue.)
- cortesoft 1y agoIf we are going to solve the revocation issue by just having very short lived certificates, then we don’t need to involve DNS at all. Just have short lived certs.
- cyphar 1y agoWell sure, that is the argument behind short-lived certs but the current standard (47 days or less) is still fairly long if you think about a targeted attack. You can't refresh your certificates every 2 minutes but you can set the DNS TTL to 2 minutes and thus stop compromised certs as soon as you discover them (plus 2 minutes). If you use DANE this is already possible but quite fragile unless you have configured your TLS certificate issuing server to have access to modify your DNS records (which is probably less safe overall).