You can request 6-day certificates from Let's Encrypt. There's a clear path towards 24-hour certificates. This will be pretty much equivalent to the current status quo with the OCSP stapling.
Is that live yet? (Not asking to be critical; I was keeping an eye out because I wanted to migrate but last I saw, 6 day certs were still in testing-only).
I never understood why they didn’t tried to push OSCP into DNS.
You have to trust the DNS server more than you trust the server you are reaching out to as the DNS server can direct you anywhere as well as see everything you are trying to access anyhow.
TLS is to protect you from malicious actors somewhere along your connection path. DNS can't help you.
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.
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...
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?
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.
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?
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.)
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.
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).
Because one of the main things TLS is intended to defend against is malicious / MITM'd DNS servers? If DNS was trustworthy then the entirety of TLS PKI would be entirely redundant...
In practice, TLS certificates are given out to domain owners, and domain ownership is usually proven by being able to set a DNS record. This means compromise of the authorative DNS server implies compromise of TLS.
Malicious relaying servers and MitM on the client is already solved by DNSSEC, so it's not adding anything there either.
If we got rid of CAs and stored our TLS public keys in DNS instead, we would lose relatively little security. The main drawback I can think of is the loss of certificate issuance logs.
> In practice, TLS certificates are given out to domain owners, and domain ownership is usually proven by being able to set a DNS record. This means compromise of the authorative DNS server implies compromise of TLS.
Yes, except for CT, which can help detect this kind of attack.
> Malicious relaying servers and MitM on the client is already solved by DNSSEC, so it's not adding anything there either.
I'm not sure quite what you have in mind here, but there is more to the issue than correct DNS resolution. In many cases, the attacker controls the network between you and the server, and can intercept your connection regardless of whether DNS resolved correctly.
> If we got rid of CAs and stored our TLS public keys in DNS instead, we would lose relatively little security. The main drawback I can think of is the loss of certificate issuance logs.
This may be true in principle but has a very low chance of happening in practice, because there is no current plausible transition path, so it's really just a theoretical debate.
> This may be true in principle but has a very low chance of happening in practice, because there is no current plausible transition path, so it's really just a theoretical debate.
Well, DANE exists and provides an obvious transition path, as brittle of an approach it is. Ideally you would be able to create your own intermediates (with name constraints) and pin the intermediate rather than the lead certificate, but PKI isn't set up for that.
From my understanding, the biggest issue with DNSSEC is that it's just a return to the single signing authority model that TLS used in the 90s. Isn't it also just Verisign again? (At least for .com.)
That is a problem, but beyond the philosophical problem (which I care a lot about) and the cryptographic problems (which I care a lot about), most of the reason DANE isn't taken seriously (is, in fact, a dead letter with the browsers, meaning it's a dead letter everywhere) are practical issues deploying it. Stipulate, very unrealistically, that a sizable portion of the most popular zones were signed (the opposite is true). Then:
You still have the problem where a substantial cohort of Internet users can't resolve DANE records. They're on Internet paths that include middleboxes that freak out when they see anything but simple UDP DNS records. You can't define that problem away.
So now you need to design a fallback for those users. Whatever that fallback is, you have to assume attackers will target it; that's the whole point of the exercise. What you end up with a system that decays to the natural security level of the WebPKI. From a threat model perspective, what you've really done is just add another CA to the system. Not better!
DANE advocates tried for years to work around this problem by factoring out the DNS from DANE, and stapling DANE records to TLS handshakes. Then someone asked, "well, what happens when attackers just strip that out of the handshake". These records are used to authenticate the handshake, so you can't just set "the handshake will be secure" as an axiom. Nobody had a good answer! The DANE advocates were left saying we'd be doing something like HPKP, where browsers would remember DANE-stapled hosts after first contact. The browser vendors said "lol no".
That's where things stand. The stapling thing was so bad that Geoff Huston --- a DNS/DNSSEC éminence grise --- wrote a long blog post asking (and more or less conceding) that it was time to stick a fork in the whole thing.
To be clear, I'm not at all a DANE advocate -- I agree with you wholeheartedly. Even if all of those problems with DANE were magically resolved it would still be an administrative nightmare to manage (especially in a world with short certificate lifetimes) and so would likely still have very little adoption anyway.
If DNS was presumed secure (i.e., secure against MITM at all points in the chain) you could just stuff the public key into a DNS record (a-la DANE) and remove the need for PKI. I'm saying there would be no need for CAs -- you could just trust self-signed certs. Some might argue DNSSEC solves this already, I'm not particularly convinced it's any better than the original CA cabal.
> then the entirety of TLS PKI would be entirely redundant...
Don't think I agree with this. TLS is important against MITM scenarios - integrity, privacy. You don't need DNS for this to be abused but a man in the middle - whether that is some open wifi, ISP or tapped into your network any other way.
If DNS was presumed secure (i.e., secure against MITM at all points in the chain) you could just stuff the public key into a DNS record (a-la DANE) and remove the need for PKI. There would be no need for the authentication provided by CAs, but you would still want to use TLS. Some might argue DNSSEC solves this already, I'm not particularly convinced it's any better than the original CA cabal.
How would that work in the current reality of the DNS? The current reality is that it’s unauthenticated and indeterminately forwarded/cached, neither of which screams success for timely, authentic OCSP responses.
Given the litigation I don’t see Qualcomm adopting any new cores whilst keeping on with developing theirs it’s going to be too risky as regardless of how many firewalls they put in place ARM could claim that their IP spilled over.
My last status is that ARM backed down from invalidating ARMs ALA license earlier this year, so Qualcomm still has an architecture license to integrate ARMs designs into their own custom cores.
I suggest you read the actual RFC. HTTP status codes are intended to represent the state of your application. HTTP is part of the application layer it is not a transport layer protocol.
reply