Re:OCSP Service Has Reached End of Life
by parliament32 on Monday September 15, 2025 @09:39AM
(#45249629)
If you had a perfectly secure DNS service, you could just stick the certificate fingerprint in DNS and be done. No need for trust stores, CAs, trust chains, OSCP/CRLs...
Re:OCSP Service Has Reached End of Life
by cortesoft on Monday September 15, 2025 @10:41AM
(#45250265)
How would you revoke a certificate? If you are running a malicious DNS server, couldn't you just refuse the update and keep servicing the prior results?
Re:OCSP Service Has Reached End of Life
by parliament32 on Monday September 15, 2025 @12:25PM
(#45251628)
If the DNS service is "perfectly secure", we're assuming MITM attacks are impossible. You wouldn't need to revoke anything, you just update the fingerprint in the record.
Re:OCSP Service Has Reached End of Life
by cortesoft on Monday September 15, 2025 @05:27PM
(#45255126)
Why would DNS being perfectly secure make MITM attacks impossible? It might be impossible to hijack DNS, but after DNS resolution happens, then the actual connection via IP address has to happen.
If you are saying every packet sent is secure, then it would have nothing to do with DNS?
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.
Re:OCSP Service Has Reached End of Life
by cortesoft on Monday September 15, 2025 @09:30PM
(#45256993)
Right, but what if the certificate is compromised? How would your revoke it?
If 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.)
Re:OCSP Service Has Reached End of Life
by cortesoft on Tuesday September 16, 2025 @11:07PM
(#45271166)
If 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.
Re:OCSP Service Has Reached End of Life
by cyphar on Wednesday September 17, 2025 @05:56AM
(#45273811)
Well 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).
Re:OCSP Service Has Reached End of Life
by waste_monk on Monday September 15, 2025 @08:01PM
(#45256430)
Indeed, this already exists with record types such as TLSA, SMIMEA, and CERT.
However I don't believe I've ever seen it used "in the wild".
Just imagine you succeeded in inventing a perfectly secure DNS server. Great, we know this IP address we just got back is the correct one for the server.
Ok, then I go to make a connection to that IP address, but someone on hop 3 of my connection is malicious, and instead of connecting me to the IP, just sends back a response pretending to be from that IP. How would I discover this? TLS would protect me from this, perfectly secure DNS won't.