Let's kill it off and focus on efforts that solve real problems. It's worse than pointless, the added complexity is a huge liability.
Certbot, which I have setup to automatically renew my wildcard Let's Encrypt certificates, has access to my master API key on DO. I try to follow the best practices in keeping it safe, but I'd prefer if that specific API key would only have the required privileges to modify a set of specifically named TXT records and nothing more.
It helps against BGP attacks. https://www.blackhat.com/docs/us-15/materials/us-15-Gavriche...
DNSSEC + a CAA record with the validationmethods parameter set to DNS would prevent that attack.
Like what? It's pointless to distract from constructive proposals with no supporting material for what the problems are with the proposed solution, and then claim there are other things that need our attention and then not even pay lip service to them.
I've only seen this sentiment every now and then in very particular circles. It's not really that famous.
Here's a fun exercise: You could just say what you need to say to make a point and educate the people reading this thread. Otherwise your comment is kind of detracting from constructive conversation.
That is a damning argument and there is nothing else to say, until someone (e.g. you, but don't feel pressured) comes forward with a good counter example.
That's not a very good argument when you're talking about securing systems. We don't actively mitigate attacks based on the prevalence of known instances of that attack. You do so beforehand. Attack vectors, before they are ever or even actively used, are considered. The most relevant, recent, and well known example of this is heartbleed.
Here is the exact change if you're able to read the code: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h... -- if that is not within your skillset to read that change, the patch is essentially doing a bounds check on a set area of memory. The language being used is notorious for allowing this type of code error and is the source of many exploits and bugs. It has nothing to do with the specification.
For some reading material see this wikipedia article on the subject: https://en.wikipedia.org/wiki/Buffer_over-read
>Programming languages commonly associated with buffer over-reads include C and C++, which provide no built-in protection against using pointers to access data in any part of virtual memory, and which do not automatically check that reading data from a block of memory is safe; respective examples are attempting to read more elements than contained in an array, or failing to append a trailing terminator to a null-terminated string. Bounds checking can prevent buffer over-reads
We mitigate against attack vectors before there are known instances of software using those attack vectors. I'm not sure why you want to argue against that, or even how because we do it all the time. Take Spectre/Meltdown as another example. Preemptive measures were taken before any known usage of that attack vector had been discovered.
Sure, the actual bug is a coding 101 bug, but the social process that caused a coding 101 bug to potentially compromise the vast majority of server installations is why Heartbleed is important. One of the lessons is that you need more reason to implement a feature than "it's a feature that can be implemented."
I don't think I am. You're focusing on one particular thing and invoking platitudes that are completely irrelevant. You're actively attempting to change the conversation topic to fit your viewpoint. That's not okay. No one is talking about the philosophy of feature development and adoption. I gave another example of where we preemptively mitigate issues that has nothing to do with philosophical waxing on "did we really need to do this" or "nobody really wanted that feature": Specter/Meltdown.
So two things, to get this conversation back on track:
1) The idea that DNNSEC is worthless/useless/bad is not "famous" by any reasonable use of that term. I explicitly stated it was only something you see in particular circles. The fact that the actual most popular piece of software used to manage DNS enables DNNSEC by default, and one of the biggest 3rd party public providers for DNS has it opt-out only is a testament to this fact. It's myopic to think that other people are aware of these things when the entire ecosystem is signaling quite the opposite.
2) DNSSEC might be useless, but in abstract terms arguing against systems designed to mitigate attacks simply because those attacks haven't been seen in the wild is a bankrupt idea in the world of security. So if you want to say DNSSEC is a bad idea then stick with that, but don't say it's a bad idea because we haven't seen an actual attack with what DNSSEC is trying to prevent. The claim again, is bankrupt when you're talking about securing systems.
>but the social process that caused a coding 101 bug to potentially compromise the vast majority of server installations is why Heartbleed is important.
I actually want to speak to this, because it's kind of a popular thing to say in the world of software development, but it fundamentally misunderstands what's actually happening.
You're right that a social process allowed the coding 101 bug to happen and exist for so long, but you're wrong about which social process. People's motivations for a feature have no bearing on how exploitable code gets written. Because features that people do want are victim to the same kind of errors in code. If you immediately falsify your perspective about which social process is in play you see it becomes irrelevant. You can completely take people's motivations out of the equation and the same process and class of error exists that allows the exploits and bugs to happen.
I am not saying that increases in LOC does not correlate with an increase in bugs. That's a fairly standard fact. I am saying that people's motivations for features have no bearing on how open source projects fall victim to shoddy code.
The social process that IS to blame is the fact that people don't invest in open source software, yet depend on it for their entire ecosystem. A student wrote some code, submitted it, and it was reviewed by one person. That code was never really looked at again, not really tested, but allowed to exist in the software for years. If the social ecosystem around open source software was one where more eyes had been laid on the code created it might not have happened all together, and relying on a student to write the code is a travesty in its own right all together.
But people's motivations for writing code? Not really relevant in terms of LOC, exploits, and code quality.
You're getting really hung up on "famously" which doesn't even literally mean "is famous". If that's your #1 point, you might as well drop it and move on to something else.
I stated as such in my comment you're replying to. The software that basically everyone uses for DNS management. Google DNS supports it by default, requiring you to opt out. I gave you an example, it would be greatly appreciated for you to provide a substantive, informative comment about the problems with DNSSEC or at the very least provide other material authored by other people (blogs/articles/etc) who are famous security experts who do not support DNSSEC -- you seem to know who to go to.
Google does not generally support DNSSEC. It's easy to find Google security engineers criticizing it, but the most notable example would be AGL's "Why Not DANE In Browsers", which discusses why Chrome stopped supporting DNSSEC.
Actually if you read exactly what I wrote I merely countered that it's not a famous sentiment, which the comment I was replying to said it was. I said it was a sentiment only seen, at least from my perspective, in particular circles and really only in passing.
I would consider the fact that Google DNS and named support it by default to be a significantly appropriate counter to the whole "everyone knows this isn't really a good tool/specification" sentiment. And it's an excellent negation of "it's easy to find Google engineers criticizing it" when their own service and the company they work/did work for is using it by default with their DNS service. Indeed, while I thank you for actually linking something I and others can read, the fact that some engineer in the ether -- and not to impugn his work, credibility, or how well he is known in certain circles -- is writing on the subject doesn't really have the same publicity as services and defacto software enabling DNNSEC by default.
Here's the important point: Because of the above, to the passing eye or as mere consumers of these tools and services it looks like a specification that would probably be a good idea and a credible one at that. There is nothing "famous" about it falling short, or being a solution in search of a problem when everyone who really matters in this space is using it.
Surely you must see that. Again thanks for the reading material, it is very much appreciated.
Things become slightly more complicated when you have to deal with broken home routers. But that code exists as well.
What you meant to say was that DNSSEC works "perfectly fine for securing requests from end-users" so long as they run their own DNSSEC cache servers. But of course, nobody is going to do that. They'll run DoH/DoTLS instead.
Maybe you want to take a look at, for example, https://getdnsapi.net/
Please stop spreading misinformation.
Another example, openssh can locally do DNSSEC validation of SSHFP records (using the ldns library). Unfortunately, it doesn't really work, but that is a different story. All of the validation code is there.
A search term you might find helpful: [DNS header AD bit].
In addition, a validating endpoint resolver is no more a "dns server", than a stub resolver is.
Not for nothing, but even the IETF doesn't want you to do this.