Re:DNSSEC needn't be a panacea to be useful.
on
DNSSEC: Good Enough?
·
· Score: 1
Hm, what I've learned is that [TCP/IP, SMTP, other aged Internet standards] work.
I agree, in a way analogous to how Microsoft Windows "works". Perhaps I'm expecting too much, but that's simply not good enough.
But if we have something that's a significant incremental improvement, and don't have the complete panacea, is it a mistake to use what we have? It sounds like you're saying it is.
I'll continue with the Microsoft analogy: every one of the 40-some-odd security and bugfix updates I had to apply the last time I installed Windows on a machine was a 'significant incremental improvement'. Incremental improvements necessitated by flawed design, IMHO, are simply not good enough- especially when we know they're not good enough before we even implement them! This is even more true when we try to use them as building blocks for the future.
I'm not trying to equate DNSSEC and Windows- but similar, really the same, concepts are involved. Poor design necessitates more and more of these significant incremental improvements. With Windows, it's marginally acceptable to apply these improvements; if you're one of the many who don't like doing that, there are choices of other software to run on your computer. But how do you 'patch' an Internet standard once it's been widely deployed, with a lot of time and effort spent to implement this in software applications? And unlike Windows, there is *no* choice. If someone says 'I want a protocol for publishing and resolving names to IP addresses on the Internet', what option does s/he have other than DNS?
That's not a very good attitude for an engineer to have - you never get anything done with that attitude.
It does indeed take more time to realize a complete, properly deisgned solution than one that is an incremental improvement. But this does not equate to 'never getting anything done'- it simply requires more patience. I am very willing to be patient in that case.
It's unfortunate that BIND 8 and BIND 9 are always discussed by DJB and his acolytes as if they are the same product, when in fact they are two completely separate code bases, one of which was in fact engineered to specifically avoid the failings of the other.
Whether it's BIND version 4, 8, or 9 is of minor importance. I don't trust the people writing the code, and here's why: I'm aware that the ISC says BIND 9 was a complete redesign from previous versions. I haven't read the source code to see if this is actually true or not, but I'll take their word for it for purposes of this discussion. I appreciate the fact that they recognized the problems caused by poor design in previous versions, and did the right thing- rewrote it from scratch. But it didn't take very long for attackers to be able to kill a BIND 9 server with a malformed DNS packet or find remotely exploitable buffer overflows in BIND 9's resolver library. (If you're unclear or doubtful on what vulnerabilities I'm referring to, I'll be happy to provide references.)
Whether the ISC is lying about BIND 9 being a complete rewrite, or they have simply done a poor job implementing their finally-got-it-right-this-time design, or whatever the reason, matters very little. I wouldn't trust them to sit the right way on a toilet seat.
In contrast, Bernstein's still sitting on the $500 reward for finding similar security holes in djbdns. My own experience with BIND and djbdns has shown me BIND is not particularly high quality software, and that the problems encountered with BIND don't appear in djbdns. Given the choice between these software packages, does my choice of djbdns over BIND seem unreasonable?
It would be much more fun to debate these points if we were actually talking about the merits of each software package, rather than tarring one with the same brush as the other.
BIND's ugly history, regardless of version, is well documented by many third parties (not ISC or DJB: CERT, for example, has all the info one n
...proposed solution `nym' seems quite nutty.... He basically proposes only allowing a form of hostname which is (1) too long to type manually, and (2) includes long random-looking strings.
So, your issue with nym is not that it doesn't offer a simple and effective layer of security, but that it threatens the convenience and useability you and others have become accustomed to. Is that accurate?
Is it news to you? Security and convenience/useability are almost always tradeoffs. Because you and many others (myself included) don't immediately see a way to do your job, hop around on the Internet, or what have you, with comparable convenience to the ways you perform these tasks now, you discredit nym as 'nutty' or 'wacky'? Why is it impossible, or outlandish, or nutty to devise an equally simple and effective mechanism to limit or eliminate the inconvenience nym would cause? If Bernstein had developed both simultaneously, would you still be complaining?
His justification for this is `users seem to do alright with bookmarks, and as soon as everything is links, no problem!'
Well, how dare he come up with an idea for DNS signatures that completely avoids the problems of DNSSEC, without making sure it's to everyone's liking first! Clearly, Bernstein's comment about bookmarks is not a proposed ideal solution: he admits candidly it's a problem- today. Are you willing to make some sacrifices of convenience today for the sake of security? If not- why? Are you aware of the sad state of security in information technology today- where Slammer, a trivial 376-byte program, is capable of utterly crippling many systems that everyone depends on for anything and everything, to name just one example?
Regardless of the pros and cons of nym, we as a community and as computer scientists, have to be smarter than this- I would expect such sentiments from Windows users who think they are 'network administrators' because they know how to right-click on TCP/IP Settings, and shy at the thought of editing a text file on the command line to accomplish the same task.
Re:DNSSEC needn't be a panacea to be useful.
on
DNSSEC: Good Enough?
·
· Score: 1
DNSSEC provides a secure key distribution mechanism. Right now, the only secure key distribution mechanism on the Internet is the SSL key mechanism...
You apply the description 'secure' as though security was a switch to be toggled on or off, or that in such black and white terms, it's even possible. Any such claim is either ignorance or mere lip-service: I don't place trust in "Trustworthy Computing" because Microsoft calls it trustworthy. (I don't place trust in it at all, but that is beside the point.) Nor should anyone believe there is such a thing as 'security' that is really secure in and of itself, much less because someone claims it to be so.
DNSSEC provides a layer of security; a countermeasure. It absolutely does need to be a panacea- as close to it as we, as fallible humans, are capable of designing. Have we learned nothing from the weaknesses of TCP/IP, SMTP, and the like? Have we learned nothing from the problems that arise from designing architectures on which to build future technology, when unrealistic assumptions continue to be made about the environment they will exist in? The failures of past implementors (like Mockapetris, ironically) can be excused, on one condition: present and future implementors must learn from their mistakes, and avoid them.
Keeping this in mind, is it obtuse of me to discard, nay, to vehemently reject and persecute 'good enough' solutions as building blocks for the future?
DJB says that BIND doesn't do DNSSEC very well. It's true that BIND 8 doesn't do as well as BIND 9. If you want to spend some money, my employer will sell you something even nicer.
OT: BIND has a proven past and present of not doing a whole helluva lot very well. Also OT: Your employer, whether they call themselves Nominum or the Internet Software Consortium or whatever mask they choose to wear, writes/has written/continues to write both the perpetually buggy BIND software, and writes and sells the 'nicer' commercial software, correct? What justification, other than the desire to make more money for themselves, do they give for selling (supposedly) high-quality software and offering provably low-quality software (that runs the root nameservers, no less) to the community?
DNSSEC is a half-assed attempt at getting things done the quick and dirty way. Mockapetris wants his name in a few more RFCs; the BIND/ISC/Nominum people need another impressive but misleading tagline to further their marketing efforts.
Slashdot Mirror
Hm, what I've learned is that [TCP/IP, SMTP, other aged Internet standards] work.
I agree, in a way analogous to how Microsoft Windows "works". Perhaps I'm expecting too much, but that's simply not good enough.
But if we have something that's a significant incremental improvement, and don't have the complete panacea, is it a mistake to use what we have? It sounds like you're saying it is.
I'll continue with the Microsoft analogy: every one of the 40-some-odd security and bugfix updates I had to apply the last time I installed Windows on a machine was a 'significant incremental improvement'. Incremental improvements necessitated by flawed design, IMHO, are simply not good enough- especially when we know they're not good enough before we even implement them! This is even more true when we try to use them as building blocks for the future.
I'm not trying to equate DNSSEC and Windows- but similar, really the same, concepts are involved. Poor design necessitates more and more of these significant incremental improvements. With Windows, it's marginally acceptable to apply these improvements; if you're one of the many who don't like doing that, there are choices of other software to run on your computer. But how do you 'patch' an Internet standard once it's been widely deployed, with a lot of time and effort spent to implement this in software applications? And unlike Windows, there is *no* choice. If someone says 'I want a protocol for publishing and resolving names to IP addresses on the Internet', what option does s/he have other than DNS?
That's not a very good attitude for an engineer to have - you never get anything done with that attitude.
It does indeed take more time to realize a complete, properly deisgned solution than one that is an incremental improvement. But this does not equate to 'never getting anything done'- it simply requires more patience. I am very willing to be patient in that case.
It's unfortunate that BIND 8 and BIND 9 are always discussed by DJB and his acolytes as if they are the same product, when in fact they are two completely separate code bases, one of which was in fact engineered to specifically avoid the failings of the other.
Whether it's BIND version 4, 8, or 9 is of minor importance. I don't trust the people writing the code, and here's why: I'm aware that the ISC says BIND 9 was a complete redesign from previous versions. I haven't read the source code to see if this is actually true or not, but I'll take their word for it for purposes of this discussion. I appreciate the fact that they recognized the problems caused by poor design in previous versions, and did the right thing- rewrote it from scratch. But it didn't take very long for attackers to be able to kill a BIND 9 server with a malformed DNS packet or find remotely exploitable buffer overflows in BIND 9's resolver library. (If you're unclear or doubtful on what vulnerabilities I'm referring to, I'll be happy to provide references.)
Whether the ISC is lying about BIND 9 being a complete rewrite, or they have simply done a poor job implementing their finally-got-it-right-this-time design, or whatever the reason, matters very little. I wouldn't trust them to sit the right way on a toilet seat.
In contrast, Bernstein's still sitting on the $500 reward for finding similar security holes in djbdns. My own experience with BIND and djbdns has shown me BIND is not particularly high quality software, and that the problems encountered with BIND don't appear in djbdns. Given the choice between these software packages, does my choice of djbdns over BIND seem unreasonable?
It would be much more fun to debate these points if we were actually talking about the merits of each software package, rather than tarring one with the same brush as the other.
BIND's ugly history, regardless of version, is well documented by many third parties (not ISC or DJB: CERT, for example, has all the info one n
So, your issue with nym is not that it doesn't offer a simple and effective layer of security, but that it threatens the convenience and useability you and others have become accustomed to. Is that accurate?
Is it news to you? Security and convenience/useability are almost always tradeoffs. Because you and many others (myself included) don't immediately see a way to do your job, hop around on the Internet, or what have you, with comparable convenience to the ways you perform these tasks now, you discredit nym as 'nutty' or 'wacky'? Why is it impossible, or outlandish, or nutty to devise an equally simple and effective mechanism to limit or eliminate the inconvenience nym would cause? If Bernstein had developed both simultaneously, would you still be complaining?
His justification for this is `users seem to do alright with bookmarks, and as soon as everything is links, no problem!'
Well, how dare he come up with an idea for DNS signatures that completely avoids the problems of DNSSEC, without making sure it's to everyone's liking first! Clearly, Bernstein's comment about bookmarks is not a proposed ideal solution: he admits candidly it's a problem- today. Are you willing to make some sacrifices of convenience today for the sake of security? If not- why? Are you aware of the sad state of security in information technology today- where Slammer, a trivial 376-byte program, is capable of utterly crippling many systems that everyone depends on for anything and everything, to name just one example?
Regardless of the pros and cons of nym, we as a community and as computer scientists, have to be smarter than this- I would expect such sentiments from Windows users who think they are 'network administrators' because they know how to right-click on TCP/IP Settings, and shy at the thought of editing a text file on the command line to accomplish the same task.
You apply the description 'secure' as though security was a switch to be toggled on or off, or that in such black and white terms, it's even possible. Any such claim is either ignorance or mere lip-service: I don't place trust in "Trustworthy Computing" because Microsoft calls it trustworthy. (I don't place trust in it at all, but that is beside the point.) Nor should anyone believe there is such a thing as 'security' that is really secure in and of itself, much less because someone claims it to be so.
DNSSEC provides a layer of security; a countermeasure. It absolutely does need to be a panacea- as close to it as we, as fallible humans, are capable of designing. Have we learned nothing from the weaknesses of TCP/IP, SMTP, and the like? Have we learned nothing from the problems that arise from designing architectures on which to build future technology, when unrealistic assumptions continue to be made about the environment they will exist in? The failures of past implementors (like Mockapetris, ironically) can be excused, on one condition: present and future implementors must learn from their mistakes, and avoid them.
Keeping this in mind, is it obtuse of me to discard, nay, to vehemently reject and persecute 'good enough' solutions as building blocks for the future?
DJB says that BIND doesn't do DNSSEC very well. It's true that BIND 8 doesn't do as well as BIND 9. If you want to spend some money, my employer will sell you something even nicer.OT: BIND has a proven past and present of not doing a whole helluva lot very well. Also OT: Your employer, whether they call themselves Nominum or the Internet Software Consortium or whatever mask they choose to wear, writes/has written/continues to write both the perpetually buggy BIND software, and writes and sells the 'nicer' commercial software, correct? What justification, other than the desire to make more money for themselves, do they give for selling (supposedly) high-quality software and offering provably low-quality software (that runs the root nameservers, no less) to the community?
DNSSEC is a half-assed attempt at getting things done the quick and dirty way. Mockapetris wants his name in a few more RFCs; the BIND/ISC/Nominum people need another impressive but misleading tagline to further their marketing efforts.