Ask Slashdot: Could We Not Use DNS For a Certificate Revocation Mechanism? 97
Long-time Slashdot reader dhammabum writes:
As reported in the recent slashdot story, starting in September we system admins will be forced into annually updating TLS certificates because of a decision by Apple, abetted by Google and Mozilla. Supposedly this measure somewhat rectifies the current ineffective certificate revocation list system by limiting the use of compromised certificates to one year... But in an attempt to prevent this pathetic measure, could we instead use DNS to replace the current certificate revocation list system?
Why not create a new type of TXT record, call it CRR (Certificate Revocation Record), that would consist of the Serial Number (or Subject Key ID or thumbprint) of the certificate. On TLS connection to a website, the browser does a DNS query for a CRR for the Common Name of the certificate. If the number/key/thumbprint matches, reject the connection. This way the onus is on the domain owner to directly control their fate. The only problem I can see with this is if there are numerous certificate Alternate Names — there would need to be a CRR for each name. A pain, but one only borne by the hapless domain owner.
Alternatively, if Apple is so determined to save us from ourselves, why don't they fund and host a functional CRL system? They have enough money. End users could create a CRL request via their certificate authority who would then create the signed record and forward it to this grand scheme.
Otherwise, are there any other ideas?
Why not create a new type of TXT record, call it CRR (Certificate Revocation Record), that would consist of the Serial Number (or Subject Key ID or thumbprint) of the certificate. On TLS connection to a website, the browser does a DNS query for a CRR for the Common Name of the certificate. If the number/key/thumbprint matches, reject the connection. This way the onus is on the domain owner to directly control their fate. The only problem I can see with this is if there are numerous certificate Alternate Names — there would need to be a CRR for each name. A pain, but one only borne by the hapless domain owner.
Alternatively, if Apple is so determined to save us from ourselves, why don't they fund and host a functional CRL system? They have enough money. End users could create a CRL request via their certificate authority who would then create the signed record and forward it to this grand scheme.
Otherwise, are there any other ideas?
Cert expirations, why? (Score:3, Interesting)
I understand the theory but out here in the real world expiring cents just leads to panic the day it expires and the site effectively goes down and customers slam the help desk.
One year certs will just make this happen more often.
How about certs that can auto-update? Or just say fuck it and not expire them and let the chips fall? Let anyone who wants or needs to use a short duration cert do so and leave the rest of us alone. Why do I need to update the cert on our zero content marketing site? Why does it even need to be "protected" by ssl at all? It doesn't but we pay the fee and the hassle to keep browser makers happy. It has zero security or privacy benefit to our customers.
Re:Cert expirations, why? (Score:5, Interesting)
"out here in the real world expiring cents just leads to panic"
How comes that everybody manages to file taxes on time, renew car insurance on time, pay your mobile contract on time etc.
But websites still do not manage to update their certificate, one of the main defences against malicious attacks, on time?
Your "real world" is a place of shoddy business practices, and you should not be allowed to handle any sensitive data.
Re: (Score:2)
How comes that everybody manages to file taxes on time, renew car insurance on time, pay your mobile contract on time etc
Those things you mentioned? Those things don't happen either..
Re: Cert expirations, why? (Score:1)
And those inactions do have results. If you don't pay your cell phone bill, you don't get service, if you don't resign your contract you get evicted.
1 year certs can still be done manually. Not sure why it's such a pain.
Re: (Score:2)
Those things don't happen either.
That's true. And there are consequences when they don't.
I'd say that having some help desk calls for an expired cert is getting off light. And more than reasonable.
Re: (Score:2)
Yes, you have to file for an automatic extension for the first one and you get a late notice for the other two. Your lights don't go out at midnight on the day after the power bill was due.
Re: Cert expirations, why? (Score:2, Insightful)
Welcome to the real world.
Good luck putting an unnecessary process consistently in place at millions of sites.
Again, I ask, why does my marketing site need a cert at all?
What value is there in a one year vs three year?
We have real work to do. This is bullshit and a waste of time for most sites.
I'm so glad my favorite web comics keep their certs up to date or the sky would fall if evil forces used a man in the middle attack to see which comic episode I'm on.
Re: (Score:2)
If your job is not web hosting, why would you bother with it at all? Our host manages all our certs for the website, automated via cpanel. Internally things are much more shoddy for things like the phones or other things that just need a management interface, but that is a different beast.
Re: (Score:3)
Again, I ask, why does my marketing site need a cert at all?
Because you never know when that site might be expanded, or get referenced on another. Make encryption the norm and you won't even need to think about it.
What value is there in a one year vs three year?
The whole reason for this /. article is certificate revocation not working well. That is the reason to shorten the lifetime so that if a certificate leaks then the damage is time-limited. No, simply issuing a new certificate for the affected names doesn't help. Clients will still trust the old certificate until it expires.
We have real work to do. This is bullshit and a waste of time for most sites.
The true waste of time is not
Re: Cert expirations, why? (Score:4, Funny)
It is far worse than them spying on your viewing habits. Once they successfully run a man-in-the-middle attack against you they can serve up comics which differ in subtle ways from the original, gradually changing your views on politics and other things. They may even be able to program you to wear masks in crowded public places or accept 5G cell towers.
Re: (Score:2)
2) Self-signed certs are dangerous to trust.
Regardless of your reasoning, 1+2 means all sites should be encrypted and use a cert. We're not trying to make all sites trustworthy, we just want to make sure that sites we're connecting are the sites we're connecting to.
Re: (Score:2)
1) Unencrypted traffic has many attack vectors. The mere act of supporting unencrypted HTTP is a constant danger.
Given you are bypassing a complex TLS stack and browser misfeatures that only work with TLS sessions the attack surface of unencrypted sessions appears to me to be significantly LESS especially after factoring in users not suffering delusion of "secure" padlock icons displayed by the browser.
The boogeyman in the wire is far from the most salient threat to Internet users security and privacy. Everyone talks about the vulnerable hotspot luser and evil ISPs yet these things have never actually been a signifi
Re: (Score:2)
Most people have two primary use cases 1) Connecting to a site they know 2) Connecting to a site they found in a search 3) A 3rd-party site referenced from a secure site you're visiting
I think we all understand case 1. But case 2 still benefits from malicious interception, which can happen by having compromised system on the local network. Case 3 is the most dangerous. If you're on a website y
Re: (Score:2)
Fat fingering a URL? I haven't typed in a url in well over a decade and I don't know anyone who does. Except you.
https://www.tripwire.com/state... [tripwire.com]
https://www.theregister.com/20... [theregister.com]
https://krebsonsecurity.com/20... [krebsonsecurity.com]
Most people have two primary use cases 1) Connecting to a site they know 2) Connecting to a site they found in a search 3) A 3rd-party site referenced from a secure site you're visiting
Or the site you were told over the phone or think you remembered or someone you think you know sent you a link to in an email.
If you're on a website you trust and it references an external resource, that resource can be intercepted and replaced with someone malicious, which could scrape secret information from your current site.
This is completely backwards. Say a website I trust allows me to login using a secure authentication protocol. For the sake of argument TLS-SRP which is available in Apache, cURL and many popular TLS stacks.
The success of authentication establishes two things:
1. The site knows our s
Re: (Score:2)
Given you are bypassing a complex TLS stack and browser misfeatures that only work with TLS sessions the attack surface of unencrypted sessions appears to me to be significantly LESS especially after factoring in users not suffering delusion of "secure" padlock icons displayed by the browser.
You're opening the entire code surface of browser content processing to potentially forged data. That's a much bigger codebase than TLS.
Everyone talks about the vulnerable hotspot luser and evil ISPs yet these things have never actually been a significant source of ownage.
It's the buggy commodity home routers that have increased the viability of MITM dramatically vs the days of dialup.
As to TFA, First, CRLs are cryptographically signed so you can't just publish hashes in DNS and expect it to work as a secure CRL unless you have a way to get DNSSec or other crypto DNS protections universally deployed on endpoints. Secondly, this problem is
Re: (Score:2)
You're opening the entire code surface of browser content processing to potentially forged data.
That happens every time you browse, every site you visit and everything injected by anything the site owner lets be injected into their sites. A typical website has code in it injected by literally dozens of third parties none of whom give a damn about your best interests, you have never heard of, know or have any relationship with whatsoever.
Yes you could get owned by some 0-day injected by someone running a fake hotspot you happen to connect to and if you had used encryption perhaps you would not have be
Re: (Score:2)
With cert pinning (trivial to implement if the browser vendors ACTUALLY cared about security) self-signed certs are fine for most sites.
Re: (Score:2)
Re: (Score:2)
Cannot confirm, perhaps someone was pulling a fast one on you. Were you doing that from work?
Pinning doesn't work because browsers don't do it.
This is a classic story, everyone wants "just a minute of your time". Soon, you notice you're all out of minutes. An ant's mouthful isn't much, but they'll soon make that slice of cake disappear.
Re: (Score:1)
Re: (Score:2)
The cert at least in theory proves to the consumer of your site that your site is your site. Without a cert the consumer has no way of knowing if the man in the middle happens. Say the man in the middle decides to put a popup asking for the user to subscribe, reset their password, whatever. Instead of your site being free it is now a paid site except the money's going to the hacker and your customers will be pissed at you as well as the hacker for letting it happen.
It's all kabuki anyways because do we real
Re: (Score:1)
Car insurance and mobile phone bills are typically on auto-pay; can I do that for my certs, too - and not have to worry about updating anything on my end (like my car insurance and phone bill)?
Taxes are enforced with a threat of prison - a bit more extreme than a site down for a day or two. And even then, at least, in the US, over 10 million people every year [filelater.com] ask for an extension of several months before actually filing. Can I do that for my cert, too?
Re: Cert expirations, why? (Score:2)
Yes you can. I assume most sites do automate certificate renewal. If nothing else you can use letsencrypt to handle it automatically and for free.
Re: (Score:1)
Re: Cert expirations, why? (Score:2)
Extra cost? If your admins are good they can do it themselves using the tools they already have. Added complexity? If this is to hard your guys arenâ(TM)t very good.
Re: (Score:2)
> How comes that everybody manages to file taxes on time
Wesley Snipes laughing...
Re:Cert expirations, why? (Score:4, Informative)
You can auto-update certs. Let's Encrypt does it.
Just need to use a software like Certbot, create some scripts that send certificate update requests to your certificate authority or use one of the many certificate management servers.
And you don't need to wait until the expiration date to renew. You can renew a cert at any time.
Any admin that waits until the last day is asking for trouble.
Re: (Score:2)
Indeed. Before I started using LetsEncrypt I used StartSSL for a few years. Create a cert, set some sort of method of reminding myself to update in 11 months. Same with domain names - renew it, set reminder 11 months out.
Re: (Score:2)
Excellent! I have a smart switch that could do with a new cert, can you point me to the certbot download for smart switches?
Re: (Score:2)
Let'sa Encrypt supports ACME protocol. Try an ACME client:
https://github.com/acmesh-offi... [github.com]
Re: (Score:2)
The odds of that actually running on a smart switch are nil.
Re: (Score:1)
Re:Cert expirations, why? (Score:4, Insightful)
Let's imagine for a moment you don't use https on your marketing site and I get control over the DNS server of some user and redirect your www.yourmarketingsite.com to a bestiality porn site. Now your customer sees doggies playing happy games with women (and men) on www.yourmarketingsite.com.
You sure will be the talk of the afternoon on that customer's meeting, I can reassure you of that.
The worst bit is that you can't even avoid this. Because it wasn't your server that was hijacked by someone trying to cause harm to you, but the customer's blunder (or his ISP's) caused you the goodwill hit. Nothing you could do to avoid it, nothing you could improve on your security to not be associated with things you'd rather not be.
What people very easily overlook is that https doesn't only care about encryption but also about identity. That "the connection is insecure, the certificate doesn't match" warning isn't as much about someone being able to eavesdrop on your connection, what's even more important is that this ensures that you're actually talking with whoever you think you're talking to.
Re: Cert expirations, why? (Score:2)
I get control over the DNS server of some user and redirect your www.yourmarketingsite.com to a bestiality porn site.
Thatâ(TM)s a really dumb straw man. Your scenario could happen regardless of whether they had ssl enabled on their website or not. If the baddies have control of their servers, they can put up a letâ(TM)s encrypt cert on their server, and the whole world will think your marketing website has changed its business model.
Re: (Score:2)
Did you actually read what I wrote? Try again.
Re: Cert expirations, why? (Score:2)
He didnâ(TM)t say *their* server, he said the DNS server. The whole point of a certificate is to validate that when I get an IP address for a certain domain, that the server I hit is actually serving that domain.
Re: (Score:2)
In this case you can certainly point out how to set up a site so that google.com would point to that site instead of google without the person duped into browsing to it would notice that something's up. It would be the security discovery of the afternoon.
Re: (Score:2)
SSL is utterly irrelevant in verifying the authenticity of site ownership if the DNS record has been changed or the webserver has been hijacked.
Way to not read or understand what is written. This is what he wrote: "Let's imagine for a moment you don't use https on your marketing site and I get control over the DNS server of some user and redirect your www.yourmarketingsite.com to a bestiality porn site. Now your customer sees doggies playing happy games with women (and men) on www.yourmarketingsite.com."
He didn't say that the marketing site was hijacked. He said specifically that the DNS server record has been hijacked.
Your certificate cannot prevent me from displaying doggie porn as if you had published it. But, thanks to further contributing the utter skurity ignorance that is eroding the web and the internet.
Again way not to read or unde
Re: (Score:1)
Re: (Score:2)
They do not prove ownership, they only prove that the page pretending to be www.abcd.com is actually the site the certificate was issued for. Whether it belongs to who you believe it belongs to is outside the scope of certificates. What it does prevent, though, is DNS spoofing because either the certificate does not match the page or there is no certificate altogether.
HSTS only works after the first visit, and the only thing it really does is prevent you from accessing a page's unencrypted version after the
Re: (Score:2)
HSTS works all the time if you have submitted your site to the HSTS preload site and a new version of web browsers has been released since you submitted.
However, it does nothing to stop a hijacked nameserver that is validating certificates for the new website.
Re: (Score:2)
Re: (Score:2)
It's not just that, this idea is about as old as the web. In 1996 I was at a security conference where people were talking about using the DNS for PKI. That was quarter of a century ago.
If that was going to work, it would have worked by now.
Re: (Score:2)
The entire certificate mess is a useless contrived fiasco created by Google and now Apple.
No. It's a mess but not because of Google and Apple. Now you may not like their solution, but this wasn't a problem of their making.
Re: (Score:3)
Google started it with SSL everywhere. But, there is no need fro SSL on 90% of the internet.,
Citation needed for 90%. Does a website need SSL? No if it does not save sensitive information, does not handle payments, or does not have logins. That is however a large percentage of websites. Basically if you have your own blog site and don't care that is may be hacked, no.
Nonetheless, everyone wanting Google ranking, dutifully implemented SSL everywhere.
Not everyone wanting Google ranking should get a SSL cert. You should know that. SSL certs make sense and are all but required any website that takes credit card payment information.
Now, thanks to their iDevice popularity, Apple is strong-arming the internet with artificially abbreviated certificate lifetimes.
Describe "artificially abbreviated certificate lifeti
Re: (Score:2)
Describe "artificially abbreviated certificate lifetimes". You made an assertion without any evidence.
It was on /. a week or two ago. Apple unilaterally decided that it's browser would stop accepting valid certs with more than a 1 year lifetime.
My research says 40% of internet users have used it for ecommerce
That's not the same thing. If I visit sites A, B, and C, and I buy something from C then I will be one f the 40%. That says nothing about the usefulness of SSL for A and B.
A modest proposal: standards groups should mandate 3 year expiration. Let Apple deal with the fallout from their users. Perhaps they'll learn not to make unilateral decisions about standards after
Re: (Score:2)
It was on /. a week or two ago. Apple unilaterally decided that it's browser would stop accepting valid certs with more than a 1 year lifetime.
And how is that "artificially abbreviated certificate lifetimes"? Neither you or him have declared your opinion as fact.
That's not the same thing. If I visit sites A, B, and C, and I buy something from C then I will be one f the 40%. That says nothing about the usefulness of SSL for A and B.
My point exactly. His point was that "90%" of websites don't need SSL. Yet at the same time ecommerce is about 40% of Internet usage. My point is that for ecommerce you need to pass secure information which SSL is designed to do. He's measuring the wrong metric because even if he's right the vast majority of websites are not handling the vast majority of traffic.
A modest proposal: standards groups should mandate 3 year expiration. Let Apple deal with the fallout from their users. Perhaps they'll learn not to make unilateral decisions about standards after that.
Then let the standards grou
Re: (Score:2)
And how is that "artificially abbreviated certificate lifetimes"? Neither you or him have declared your opinion as fact.
How is it NOT? It was fine before, then an update to Safari and suddenly it isn't. Did the certs decay to mulch or something?
Meanwhile, you fail logic 101. 40% of people use e-commerce. That doesn't mean 40% of sites ARE e-commerce. If I go to 10 sites regularly and one of them is an e-commerce site, then I am among the 40% that use e-commerce but the one site that needs a cert is only 10% of the sites I visit. 90% don't need a cert.
Re: (Score:2)
Re: (Score:2)
One year certs will just make this happen more often. . . .How about certs that can auto-update? Or just say fuck it and not expire them and let the chips fall?
Do you work as an IT admin?
Why do I need to update the cert on our zero content marketing site?
You don't. Your admin does. There is a complexity of administration and infrastructure in that "zero content" marketing site. I mean you seem to think marketing site == dedicated standalone solo web server. In reality that's page is in normally part of a cluster of web servers. Add to that complexity is how cloud services are required for different functions some of which need to be secured.
Why does it even need to be "protected" by ssl at all?
Generally if one part of your web infrastructure needs to be protected; they should all be
Re: (Score:2)
How about just monitor your certs. Geez. Nagios has a check_ssl_cert plugin that works fine.
Re: (Score:2)
Actually, shorter term cert expiry may help cert expiry problems.
This generally happens because someone sets up the cert and then totally stops thinking about it, because that's years in the future.
With a shorter expiry, the annoyance forces you to implement a more robust strategy.
As to why, generally speaking people leave their private key in the clear on disks somewhere and end up in the dumpster or otherwise recovered by someone either online or offline. There are a ton of risks that are frequently ignor
Re: (Score:2)
What are you talking about?
Ssl certs are free, and setting up auto renew takes less then 60 seconds with the let's encrypt bot.
Re: (Score:2)
One year certs will just make this happen more often.
At first, I suspect so. However, as admins get used to the cadence, I suspect it will actually drop over time. One problem is with multiyear certs it's really easy to forget about them. Doing them every year, it will become more routine.
Re: (Score:2)
Re: (Score:2)
Alternate Names (Score:4, Insightful)
I do not see why multiple DNS entries are required for Alternate Names. Just look up _crr.[common name] TXT to get the list of revoked thumbprints. (Why TXT and not CRR? Because adding new types requires upgrading all DNS middleboxes in the entire Internet.)
The problem with the proposal is that (almost) the whole point of TLS is to protect you from DNS compromise. If DNS compromise is not a concern, we can ditch the whole TLS thing and just stick the public key in _pubkey.[common name]. Goodbye and good riddance, CA leeches!
Re: (Score:2)
Re: (Score:2)
You are a client DNS hijack away of your certificate becoming untrusted.
I do not particularly see why that is a problem. Sure, it is an easy DoS on that client. However, a much easier DoS when you have hijacked the client DNS is to not answer the AAAA query in the first place.
Re: (Score:2)
The problem with the proposal is that (almost) the whole point of TLS is to protect you from DNS compromise. If DNS compromise is not a concern, we can ditch the whole TLS thing and just stick the public key in _pubkey.[common name]. Goodbye and good riddance, CA leeches!
I think sticking the public key in _pubkey is a good idea. I'm just uncomfortable with size of response. Some kind of chunking scheme where you request a few bytes at a time... unless using TLS, TCP or UDP /w DNS cookies.
I know detractors and naysayers will say D.N.S is insecure. To that I have an open question to all who are willing to ponder the following:
Since when has this ever prevented even single solitary CA from not relying completely on automated systems from depending on insecure requests and re
No response means OK? (Score:1)
So, if you somehow block the DNS lookup, the cert is good? If you wanted to include DNS as a validation mechanism, it would seem better to require an affirmative response, not the lack of a negative response.
Re: No response means OK? (Score:2)
Just use secure DNS for Certificates (Score:4, Insightful)
If DNS is secure enough to use for revocations, then it's good enough to use for distributing the certificates in the first place. So just get rid of revocation, expiration, and certificate authorities. We just need to switch everyone over to secure DNS, which we should do anyway.
Of course, the current certificate authorities will do anything they can to stop this.
Re: (Score:1)
Ever hear of DANE? (Score:2)
Re: Ever hear of DANE? (Score:1)
The CA should be able to revoke (Score:2)
Re: The CA should be able to revoke (Score:2)
CRLite (Score:5, Informative)
CRLite [ieee.org] is a system that preemptively pushes all revocation information to TLS clients such as browsers (FULL DISCLOSURE, I'm on author on this). CRLite works because all valid TLS certificates are publicly known in the Certificate Transparency logs, which means all revocations can be crawled. CRLite crawls them, packages the information in a highly compressed data structure, and then pushes that to clients. Mozilla has announced that they are adopting CRLite in Firefox (see here [mozilla.org], here [mozilla.org], and here [mozilla.org]). CRLite is a better solution than CRLs and OCSP, at least until (1) we settle on a world where all certificates are extremely short-lived, say 1 week, or (2) OCSP Must-Staple is widely deployed by certificate owners and supported by TLS clients (but don't hold your breath, we're not there yet [acm.org], FULL DISCLOSURE I'm an author on this too).
Re: (Score:2)
CRLite is a system that preemptively pushes all revocation information to TLS clients such as browsers (FULL DISCLOSURE, I'm on author on this).
Can you give a short description of how it avoids DoSes via forged revocations?
(Both fakes in the things it craweld and forgeries of its notifications.)
Re: (Score:2)
CRLite is a system that preemptively pushes all revocation information to TLS clients such as browsers (FULL DISCLOSURE, I'm on author on this). CRLite works because all valid TLS certificates are publicly known in the Certificate Transparency logs, which means all revocations can be crawled. CRLite crawls them, packages the information in a highly compressed data structure, and then pushes that to clients.
The databases would be even smaller if revocation lists were not chock full of administrative bullshit.
People should have an option to get revocations that are just list of certs mistakenly issued to the wrong party or stem from an actual security breach.
Please no. (Score:1)
Let's not hack up DNS any more than we already have. TLS libraries would then need to bundle or depend on DNS resolving libraries and handle all of DNS's weirdness.
We already have OCSP, which seems to do what you're talking about, but is actually designed around what you're asking for - a replacement for CRLs. Let's improve OCSP if we need to, but let's not be lazy with Internet protocols. There's enough of that as it is...
Denial of service (Score:2)
I intercept your DNS queries and respond with "Revoked" for every certificate. Your system now bans every single certificate on the internet, and you can no longer connect to anyone.
The idea of a clearinghouse for CRL's that could be accessed in real-time is good, but it needs to be a secure channel.
Re: (Score:2)
Re: (Score:2)
DNS is (usually) not available behind proxy, (Score:2)
Many browsers reside behind http proxies. Unless they are also using DoH and assuming that is not blocked for some fascist-like reason or another, you'd basically be crippling the browsing experience.
DNS is not really a good solution for this, but (stapled) OCSP [wikipedia.org] might be, even if not without it's flaws).
Re: (Score:3)
If you can do DNS lookup to get to the website, you can also do DNS lookup to get the TXT records. DNS does not travel over HTTP.
Also, blocking DoH has its very valid reasons, like companies doing split DNS, and companies caring about their IT security.
Re: (Score:2)
Re: (Score:2)
DNS does not travel over HTTP.
That's changing, though [wikipedia.org]
Re: (Score:2)
There is already an RFC for this (Score:2)
It was proposed to use SRV DNS records for discovery of PKI resources in 2006. The revocation list would not be directly embedded in DNS but the URL for the revocation mechanism would be (OCSP URI).
https://tools.ietf.org/html/rf... [ietf.org]
More recently a more secure and elaborate system was proposed using DNSSEC. This would actually make CA's almost unnecessary and make DNS the authoritative source for identity verification.
https://tools.ietf.org/html/rf... [ietf.org]
FYI
Revocation is not the problem (Score:2)
A revocation mechanism exists and that works. The problem is one of identification. Before any certificate can be revoked it needs to be identified as fraudulent. The shortened validity period does little more than reduce the time a fraudulent certificate remains *unidentified* in circulation.
Why not DANE? (Score:2)
What I want to know is why DANE (which is supposed to store information about the certificate in a way that avoids problems with CRLs and rogue CAs) isn't more widely adopted.
If I understand DANE properly, it holds a fingerprint for the current certificate (and secures it with DNSSEC). If a certificate is revoked, the DANE record is updated and no longer points to the revoked certificate. And if there is a rogue or bogus certificate created (e.g. via a hacked CA or via some government ordering a CA in their
Re: (Score:2)
Because the idiots who maintain browsers can't imagine relying on anything that doesn't run over HTTP, and have repeatedly refused to put it into their core systems.
DANE can be used to replace revocation. It can be used to replace the whole damned idiotic CA trust infrastructure. It's way more effective than "certificate transparency" or any of the other fool Rube Goldberg hacks that people keep creating to try to work around the evils of that giant CA trust list.
But there are a lot of fools out there. Ther
Re: (Score:2)
But there are a lot of fools out there. There also seem to be vested CA interests deliberately spreading FUD against DANE. There are also a lot of people also fighting the DNSSEC deployment that you need to support DANE (often by ignoring the fact that DANE exists and then claiming that DNSSEC doesn't add value because "securing IP lookups isn't enough").
I'm one of those fools. Fuck DNSSEC until DNS transport fixes are actually deployed. When that happens I'll be a cheerleader for it. Right now it's not worth the price of insane levels of DDOS amplification.
Re: (Score:2)
You've found the one actually sane issue.
But any DNS over UDP is an amplifier. DNSSEC isn't different in kind. For that matter, any stateless query protocol over UDP has the same problem.
If you want to kill DNS over UDP, I will be cheering you on (please just don't stick HTTP into the mix in the process). And if you want to find ways of cutting down on the number of TCP handshakes involved in doing so I'll be cheering you on even more (just try not to centralize the DNS too much).
The real root caus
Re: (Score:2)
But any DNS over UDP is an amplifier. DNSSEC isn't different in kind
Agreed. A pinhole and a 50ft gash both let water into a boat.
For that matter, any stateless query protocol over UDP has the same problem.
There is a cheap easy solution... https://www.ietf.org/rfc/rfc78... [ietf.org]
If you want to kill DNS over UDP, I will be cheering you on (please just don't stick HTTP into the mix in the process).
This is nice too https://www.ietf.org/rfc/rfc80... [ietf.org]... Don't care so long as a fix gets deployed. It could be DNS over HTTP over TLS over IPoXML.
The real root cause of UDP query amplification DDoS, DNS and otherwise, is of course in the IP routing layer, which really should be guaranteeing the provenance of packets it delivers, but does not. Asymmetric routing seemed like a good idea at the time. Not sure what to do about it now; the network operators don't want to move.
The vast majority of operators already have.
Re: (Score:2)
The cookies look good, but they do still force somebody to keep some state. Just saying. Also, they're only for DNS, so the next time somebody decides to dream up some "high performance blah retrieval" protocol, and doesn't think to include something like that, you get a new crop of amplifiers popping up.
Have people started doing RPF in the Internet core now? Because what you need to really solve DDoS is truly pervasive enforcement of symmetric routing, throughout
Re: (Score:2)
The cookies look good, but they do still force somebody to keep some state. Just saying
DNS servers are issuing stateless cookies. Verification occurs without server having to remember anything about any client. Clients need to remember if they don't want to keep burning round trips.
Also, they're only for DNS, so the next time somebody decides to dream up some "high performance blah retrieval" protocol, and doesn't think to include something like that, you get a new crop of amplifiers popping up.
It's not just availability of the network to punt packets at play it is availability of DNS infrastructure. Significantly increasing incentives for it to be attacked when that can be easily avoided is irresponsible. It REMAINS irresponsible regardless of any action or inaction of any other party for any other t
Why reinvent the wheel? (Score:1)