It has to be one signature, however, for a practical reason: The top level domain zones change every hour. You're not going to get a dozen organizations to sign off on each of those changes every hour, in any practical or meaningful way.
DNSSEC is a protocol similar to, but not compatible with DNS. It is difficult to deploy and requires much more powerful hardware than current DNS servers otherwise require. DNSSEC offers no security guarantee unless DNS is completely replaced with DNSSEC.
dnscurve, on the other hand, is fully backwards compatible with DNS, would be dead-simple to deploy, requires a fraction of the computing power than DNSSEC requires, and it can be deployed incrementally.
Because the one thing I'm sure Microsoft is saying, is that they want more choices for the desktop.
Meanwhile, if you're tired of people using arguments involving "right and wrong" with things you have no better argument for, go away. This is slashdot, where everything is either right, or wrong.
"The government" isn't in the way. Without the government monopoly, there wouldn't be high speed Internet in this region at all- it took a municipality to take taxes and drag fiber.
The problem is that it isn't enough. Without regulation, the municipality simply provides the minimum requirements of their charter- how much Internet to buy and sell and at what prices.
I want more and better Internet. I cannot pay anyone in the area to give it to me. The solution isn't to get rid of the Internet all together, but to encourage others in my area that there is a problem.
I think this underscores the problem is one of contentment, and has nothing to do with who in particular is subjugating us: As long as comcast is nervous about it's customers, comcast will continue to improve things. Likewise, if the members of my community complained loudly, our municipality would improve.
That means we need more regulation- not less- in order to make things better.
Our township has a municipality which provides electric, sewer, cable, and (you guessed it!) Internet.
In order to "vote" against this municipality, you also need to go "off grid" because they jack up utilities to help monopolize the local Internet service.
Additionally, we're still 1954-style copper and so the only fiber loops are from: the municipality. Hauling a DS3 from the next-nearest site would be tens of thousands of dollars for the install (Verizon tenatively quoted us 56K$USD).
There was a big project called "Network Maryland" where the whole state was supposed to get fiber construction- but they stopped just a mere 25 miles away. We paid taxes, so that the rest of Maryland could get high-speed internet, and the freedom of choice, and we just got screwed out of it.
No other ISP can compete with them here- so we don't have any others.
Here: You have to vote with your vote, and that means going door-to-door, and convincing locals to vote for something that frankly, they just don't care very much about.
Please stop telling people how content you are. You're contributing to the controversy which helps companies like Comcast, and makes things much harder for people actually trying to "vote".
I'm interested in hearing more about the group+user addresses. Do you have any documentation about that?
I don't think the weird shit system administrators really is evidence that user-extensible addresses (as opposed to administrator-extensible addresses) were common or even available before qmail, although I'd still be interested to know if you are sure that they were.
I'm sorry, that link indicates that there's another bug in BIND. It doesn't say djbdns and MaraDNS are vulnerable to this attack; just merely that source port filtering is not enough to withstand a 1gbp/sec sustained attack.
Please point to a link that says that attack works on djbdns and MaraDNS. I cannot find anything that supports your statement.
I haven't looked at MaraDNS, which is why I said I don't know about it.
I don't see how that attack would work against djbdns because djbdns doesn't accept answers to questions it didn't ask, and a remote user cannot force dnscache to ask questions.
I'm not sure what world you're in but BGP peers do not route-filter everywhere.
Prove it.
Publish a route for 207.68.160.190/32 to any AS besides AS8075. Your publishing must be visible from AS21863. I will monitor and log ALL BGP announcements I receive for 207.68.160.190/32 for the lest two weeks.
If you can do this, I would love to know what your ISP is.
Every ISP I've dealt with route-filters their peers to prevent you from doing that. It would be a small thing for them to source filter packets as well, and would obviate almost all of these UDP-based spoofing attacks.
I suspect strongly, however, that you are full of shit.
But, there are cases of things like stealth masters that do keep track of all of its slaves, and these can tell the slaves to come look for new information. Not allowing updates to the slaves because of TTLs would create a non-needed time gap in propagation.
That's a terrible reason to allow such a large security hole.
You should have to list all of your ignore-ttl-from hosts, and src-filter communication to those sites before you should be allowed to do this.
That said, you could also use some other communication channel- such as the master sshing over to the cache and flushing the cache. Certainly that's safer and easier.
They would have to know all of the caches in order to push the changes to them, and since caches can cache for caches, it's unrealistic that a normal site could know this, and unlikely that a specially designed site would.
The cache should not cache answers to questions it didn't ask, and that includes new authorities for the domain.
how come the same vulnerability is present on other DNS servers as well ?
It isn't. djbdns for example, is not affected. I don't think maradns is affected either.
Do they all use the same code from BIND for this particular 'feature' ?
Very likely.
BIND has a very permissive license; most other DNS servers exist to facilitate lock-in with a particular vendor's stack, or to push some enhanced feature set, so they'd be considered foolish if they didn't copy BIND's source code where they could.
If this is indeed not a protocol flaw,
Well, I'm not sure it is unfair to call this a protocol flaw. Maybe a design flaw.
BIND has resisted port randomization because "the RFC said so"- never mind that they wrote the RFC, and that no clients bother checking. Because it stopped spoofing attacks ten years ago, and it stops them today, most DNS servers- including those derived from BIND- do this.
BIND also uses these very complicated credibility rules for determining if it can override existing cache-knowledge. This can presumably save one or two queries per dot, but surely it would be safer to only cache answers to questions that were asked. That is, by the way, what djbdns does.
Most DNS spoofing attacks can also be solved by solving most blind spoofing attacks. There's a little reluctance to do so, because it makes things like DNSSEC largely obsolete for their intended audience. As a result, we see a lot of chest thumping and stomping in the temper tantrum. You can tell when you're about to get into one because they start by saying "If we just switched to DNSSEC by now, we wouldn't be having this problem."
Of course, since BGP peers now route-filter everywhere on the internet (they didn't used to!), mandatory source filtering is a completely possible and realistic way to stop this and other similar problems...
It is the delimiter, originally created as such by the authors of the very first MTA
But it didn't originate with Sendmail. The practice originated with qmail, and it's always been in qmail. Sendmail and Postfix added it in response to mail, and they obviously did it wrong.
There's no reason you shouldn't use - except for the problem that crops up when you have a user named bob and another user named bob-foo which is that bob can't make a.qmail-foo that works. Never mind the fact that the administrator might have made a bob-foo for this exact reason
And by the way: The + can most certainly be part of a username- I don't know where you got the idea that it couldn't be. The only (printable 7bit) character that cannot be part of a username (on unix, in it's most common configuration) is the: and it is entered into an email address as \:
You are attempting to argue that TLS/SSL is useless unless it can provide absolute security.
Balderdash. I'm arguing that you shouldn't say shit like this:
A CA-signed certificate guarantees that your data can only be decrypted by the intended recipient.
Stop it.
The use of CAs reduces uncertainty compared to the same communication without them.
It reduces uncertainty marginally. If users knew just how marginal the security afforded by TLS/SSL, they wouldn't be so quick to enter their personal details. I suspect you probably know this.
You'll check again, and I said nothing about absolute security: I'm saying it's about as safe entering your credit-card in the clear as it is using an SSL/TLS encrypted channel. This perhaps wasn't true when SSL was first introduced, but it's true now.
That means you're arguing some false security is better than no security. Even if it costs a lot of cpu-time, makes it easy for people to DoS your server, slows down your connection, and gives money to people who don't deserve it.
That is your prerogative, but I'll still call you total cock-for-brains stupid, and encourage people not to listen to you.
Absolutely? No one. Good enough, most of the time? All of the ordinary certificate authorities.
How do you trust someone "most of the time"?
Is that, most of the time you're entering private and personal information? Or most of the time that you're browsing the web?
The threat that the efforts of these ordinary certificate authorities protect against is almost non-existent, and yet the threats that they don't protect against are significant.
Packet sniffing credit cards and passwords is actually extremely uncommon these days. Many sites route-filter, and these protections could be obtained in other ways.
SSL is expressly designed to provide identification information, and because they don't do this, and because there are SSL providers that sign for 30$, SSL doesn't provide any realistic measure of security.
It also isn't the massive breach you're trying to present it as.
Certificate authorities aren't the panacea that you're trying to present it as.
revocation procedures were already in place to deal with it.
No they weren't.
Windows almost never reloads the CRLs for code-signing, and there's no distribution network for delivering them.
It's only designed to make it much more difficult to pass oneself off as a trusted organization,
In any event, the problem is that SSL makes people believe it's secure. You even misspoke earlier when you said:
A CA-signed certificate guarantees that your data can only be decrypted by the intended recipient.
We know this isn't true. You meant to say it provides guarantees that it only be decrypted by the specified recipient, which is an entirely different thing.
Identifying who is being specified, versus who is being intended is a muddled area that negates the minimal security benefits SSL actually provides.
Just out of curiosity, do you do the same thing offline?
Do what thing?
The fact is that phishing websites, and asp/php worms are far more common than a waitress stealing my credit card.
Furthermore, if she steals my credit card, it is more likely she will be caught, than the operators of those phishing websites.
So why exactly do you think I need to require the same burdens offline that I do online?
A CA-signed certificate guarantees that your data can only be decrypted by the intended recipient.
I'm not trying to say that a CA-signed certificate is an absolute guarantee of identity.
...
If you can actually trust the certification authority, and everyone follows all the rules and keeps their private keys secure, and the private keys aren't broken by brute force or cryptoanalysis, then the authentication will be valid.
You don't think that sounds like a mighty big if?
Who exactly do you think is worthy of that trust?
You aren't going to find absolute security anywhere.
Are you trying to indicate that bad security is better than no security?
There is always the possibility that someone, somewhere, may fail to uphold their part of the protocol.
This isn't some abstract possibility we're talking about.
TLS/SSL is still a significant improvement over systems without certificates or CAs, which would be insecure even if perfectly implemented.
I disagree. As it stands, TLS/SSL lulls users into a sense of security that is not provided or deserved. The user doesn't know if their data is safe, and the fact is TLS doesn't make any guarantees that the data is safe.
I think users should be scared shitless by any web site that asks them to enter any personal information- browser-padlock or not.
A CA-signed certificate guarantees that your data can only be decrypted by the intended recipient. There's no way to tell whether a self-signed certificate belongs to the intended recipient or a MITM, which renders the encryption useless against a determined attacker.
No, they don't.
It guarantees it using a very narrow definition of guarantee that is orthogonal to reality: The point of a CA is that if the user trusts Verisign's judgement, and Verisign says they trust eaeaea1234 is "Microsoft Corp", then the user can decide whether they can chose to decide whether they trust "Microsoft Corp" or not.
That means trusting "Microsoft Corp"'s judgement, and their track record with keeping things secure. It also means trusting Verisign's judgement, and their track record with keeping things secure.
If "Microsoft Corp" isn't Microsoft Corportation, or Microsoft Corporation cannot keep their keys safe, then the certificate adds no security whatsoever.
If you (the user) cannot trust Verisign to handle that verification process completely, then the act of having a CA adds no security at all.
Moreover: Because users are being told (by people "good at computers" like you, no doubt) that CA certificates make them secure, they believe as long as it says "Microsoft Corp", that their information is safe.
Please stop perpetuating myths about SSL. It's broken. It's been broken for a long time.
There are lots of ways to protect against spoofed replies that are far simpler than DNSSEC. Random ports and only accepting in-bailiwick answers stop a lot of short-range attacks, and RP filtering stops the long-range ones.
If you brought your computer in to Best Buy and said you couldn't play videos- and the techs there saw your naughty pictures in "Your Documents" you took with your wife (or husband), you'd be feeling similarly embaressed.
You could probably expect that the Geek Squad would not upload your pictures to 4chan. You should also be able to count on your hosting provider to show a similar level of discretion.
However you can't say the Best Buy was violating your privacy- not intentionally, not clearly. It seems what happened with your mysql was likely an accident- I see no reason to believe otherwise, and you don't seem to either- you're just grasping around their privacy policy like it somehow matters.
Exactly what kind of attack are you less vulnerable (or invulnerable) to now that you've installed DNSSEC?
DNSSEC doesn't protect against most of the problems using DNS as an attack vector- bugs in BIND and derivatives- DJBDNS has always been secure against this attack.
I paid 6K for a Gateway router, a 608 and a 532, and a couple 4pt D-Link ethernet boards. Direct from Imagestream.
I also got support at 3AM when Sprintlink's core BGP died a number of years ago, and when QWEST switched me from a Juniper to some Cisco with broken MLPPP implementation.
The problem is that DNSSec doesn't do anything. It requires an infrastructure of trustworthy certificate authorities (like Verisign). It's akin to "SSL-encrypt everything and damn the costs".
Of course, it might be useful if DNSSec actually solved any issues that we're having, but it doesn't. DJBDNS is immune to this design flaw in BIND even though this design flaw has been brought up many times before. The real message you should be taking away from this is, and they expect us to trust them?
Slashdot Mirror
It has to be one signature, however, for a practical reason: The top level domain zones change every hour. You're not going to get a dozen organizations to sign off on each of those changes every hour, in any practical or meaningful way.
DNSSEC is a protocol similar to, but not compatible with DNS. It is difficult to deploy and requires much more powerful hardware than current DNS servers otherwise require. DNSSEC offers no security guarantee unless DNS is completely replaced with DNSSEC.
dnscurve, on the other hand, is fully backwards compatible with DNS, would be dead-simple to deploy, requires a fraction of the computing power than DNSSEC requires, and it can be deployed incrementally.
Because the one thing I'm sure Microsoft is saying, is that they want more choices for the desktop.
Meanwhile, if you're tired of people using arguments involving "right and wrong" with things you have no better argument for, go away. This is slashdot, where everything is either right, or wrong.
Around 43,200 years, actually.
I think you misunderstand.
"The government" isn't in the way. Without the government monopoly, there wouldn't be high speed Internet in this region at all- it took a municipality to take taxes and drag fiber.
The problem is that it isn't enough. Without regulation, the municipality simply provides the minimum requirements of their charter- how much Internet to buy and sell and at what prices.
I want more and better Internet. I cannot pay anyone in the area to give it to me. The solution isn't to get rid of the Internet all together, but to encourage others in my area that there is a problem.
I think this underscores the problem is one of contentment, and has nothing to do with who in particular is subjugating us: As long as comcast is nervous about it's customers, comcast will continue to improve things. Likewise, if the members of my community complained loudly, our municipality would improve.
That means we need more regulation- not less- in order to make things better.
Our township has a municipality which provides electric, sewer, cable, and (you guessed it!) Internet.
In order to "vote" against this municipality, you also need to go "off grid" because they jack up utilities to help monopolize the local Internet service.
Additionally, we're still 1954-style copper and so the only fiber loops are from: the municipality. Hauling a DS3 from the next-nearest site would be tens of thousands of dollars for the install (Verizon tenatively quoted us 56K$USD).
There was a big project called "Network Maryland" where the whole state was supposed to get fiber construction- but they stopped just a mere 25 miles away. We paid taxes, so that the rest of Maryland could get high-speed internet, and the freedom of choice, and we just got screwed out of it.
No other ISP can compete with them here- so we don't have any others.
Here: You have to vote with your vote, and that means going door-to-door, and convincing locals to vote for something that frankly, they just don't care very much about.
Please stop telling people how content you are. You're contributing to the controversy which helps companies like Comcast, and makes things much harder for people actually trying to "vote".
I'm interested in hearing more about the group+user addresses. Do you have any documentation about that?
I don't think the weird shit system administrators really is evidence that user-extensible addresses (as opposed to administrator-extensible addresses) were common or even available before qmail, although I'd still be interested to know if you are sure that they were.
BTW: Even Fido was better than UUCP.
I'm sorry, that link indicates that there's another bug in BIND. It doesn't say djbdns and MaraDNS are vulnerable to this attack; just merely that source port filtering is not enough to withstand a 1gbp/sec sustained attack.
Please point to a link that says that attack works on djbdns and MaraDNS. I cannot find anything that supports your statement.
I haven't looked at MaraDNS, which is why I said I don't know about it.
I don't see how that attack would work against djbdns because djbdns doesn't accept answers to questions it didn't ask, and a remote user cannot force dnscache to ask questions.
Prove it.
Publish a route for 207.68.160.190/32 to any AS besides AS8075. Your publishing must be visible from AS21863. I will monitor and log ALL BGP announcements I receive for 207.68.160.190/32 for the lest two weeks.
If you can do this, I would love to know what your ISP is.
Every ISP I've dealt with route-filters their peers to prevent you from doing that. It would be a small thing for them to source filter packets as well, and would obviate almost all of these UDP-based spoofing attacks.
I suspect strongly, however, that you are full of shit.
That's a terrible reason to allow such a large security hole.
You should have to list all of your ignore-ttl-from hosts, and src-filter communication to those sites before you should be allowed to do this.
That said, you could also use some other communication channel- such as the master sshing over to the cache and flushing the cache. Certainly that's safer and easier.
No, a true authority cannot push new information.
They would have to know all of the caches in order to push the changes to them, and since caches can cache for caches, it's unrealistic that a normal site could know this, and unlikely that a specially designed site would.
The cache should not cache answers to questions it didn't ask, and that includes new authorities for the domain.
It isn't. djbdns for example, is not affected. I don't think maradns is affected either.
Very likely.
BIND has a very permissive license; most other DNS servers exist to facilitate lock-in with a particular vendor's stack, or to push some enhanced feature set, so they'd be considered foolish if they didn't copy BIND's source code where they could.
Well, I'm not sure it is unfair to call this a protocol flaw. Maybe a design flaw.
BIND has resisted port randomization because "the RFC said so"- never mind that they wrote the RFC, and that no clients bother checking. Because it stopped spoofing attacks ten years ago, and it stops them today, most DNS servers- including those derived from BIND- do this.
BIND also uses these very complicated credibility rules for determining if it can override existing cache-knowledge. This can presumably save one or two queries per dot, but surely it would be safer to only cache answers to questions that were asked. That is, by the way, what djbdns does.
Most DNS spoofing attacks can also be solved by solving most blind spoofing attacks. There's a little reluctance to do so, because it makes things like DNSSEC largely obsolete for their intended audience. As a result, we see a lot of chest thumping and stomping in the temper tantrum. You can tell when you're about to get into one because they start by saying "If we just switched to DNSSEC by now, we wouldn't be having this problem."
Of course, since BGP peers now route-filter everywhere on the internet (they didn't used to!), mandatory source filtering is a completely possible and realistic way to stop this and other similar problems...
But it didn't originate with Sendmail. The practice originated with qmail, and it's always been in qmail. Sendmail and Postfix added it in response to mail, and they obviously did it wrong.
There's no reason you shouldn't use - except for the problem that crops up when you have a user named bob and another user named bob-foo which is that bob can't make a .qmail-foo that works. Never mind the fact that the administrator might have made a bob-foo for this exact reason
And by the way: The + can most certainly be part of a username- I don't know where you got the idea that it couldn't be. The only (printable 7bit) character that cannot be part of a username (on unix, in it's most common configuration) is the : and it is entered into an email address as \:
Balderdash. I'm arguing that you shouldn't say shit like this:
Stop it.
It reduces uncertainty marginally. If users knew just how marginal the security afforded by TLS/SSL, they wouldn't be so quick to enter their personal details. I suspect you probably know this.
You'll check again, and I said nothing about absolute security: I'm saying it's about as safe entering your credit-card in the clear as it is using an SSL/TLS encrypted channel. This perhaps wasn't true when SSL was first introduced, but it's true now.
That means you're arguing some false security is better than no security. Even if it costs a lot of cpu-time, makes it easy for people to DoS your server, slows down your connection, and gives money to people who don't deserve it.
That is your prerogative, but I'll still call you total cock-for-brains stupid, and encourage people not to listen to you.
How do you trust someone "most of the time"?
Is that, most of the time you're entering private and personal information? Or most of the time that you're browsing the web?
The threat that the efforts of these ordinary certificate authorities protect against is almost non-existent, and yet the threats that they don't protect against are significant.
Packet sniffing credit cards and passwords is actually extremely uncommon these days. Many sites route-filter, and these protections could be obtained in other ways.
SSL is expressly designed to provide identification information, and because they don't do this, and because there are SSL providers that sign for 30$, SSL doesn't provide any realistic measure of security.
Certificate authorities aren't the panacea that you're trying to present it as.
No they weren't.
Windows almost never reloads the CRLs for code-signing, and there's no distribution network for delivering them.
Apparently it fails at that too.
In any event, the problem is that SSL makes people believe it's secure. You even misspoke earlier when you said:
We know this isn't true. You meant to say it provides guarantees that it only be decrypted by the specified recipient, which is an entirely different thing.
Identifying who is being specified, versus who is being intended is a muddled area that negates the minimal security benefits SSL actually provides.
Do what thing?
The fact is that phishing websites, and asp/php worms are far more common than a waitress stealing my credit card.
Furthermore, if she steals my credit card, it is more likely she will be caught, than the operators of those phishing websites.
So why exactly do you think I need to require the same burdens offline that I do online?
You don't think that sounds like a mighty big if?
Who exactly do you think is worthy of that trust?
Are you trying to indicate that bad security is better than no security?
This isn't some abstract possibility we're talking about.
I disagree. As it stands, TLS/SSL lulls users into a sense of security that is not provided or deserved. The user doesn't know if their data is safe, and the fact is TLS doesn't make any guarantees that the data is safe.
I think users should be scared shitless by any web site that asks them to enter any personal information- browser-padlock or not.
You mean, like taking over the destination? Or their ISP? Or maybe their upstream?
Seriously.
It's not like that never happens.
Someone ought to tell Verisign that.
No, they don't.
It guarantees it using a very narrow definition of guarantee that is orthogonal to reality: The point of a CA is that if the user trusts Verisign's judgement, and Verisign says they trust eaeaea1234 is "Microsoft Corp", then the user can decide whether they can chose to decide whether they trust "Microsoft Corp" or not.
That means trusting "Microsoft Corp"'s judgement, and their track record with keeping things secure. It also means trusting Verisign's judgement, and their track record with keeping things secure.
If "Microsoft Corp" isn't Microsoft Corportation, or Microsoft Corporation cannot keep their keys safe, then the certificate adds no security whatsoever.
If you (the user) cannot trust Verisign to handle that verification process completely, then the act of having a CA adds no security at all.
Moreover: Because users are being told (by people "good at computers" like you, no doubt) that CA certificates make them secure, they believe as long as it says "Microsoft Corp", that their information is safe.
Please stop perpetuating myths about SSL. It's broken. It's been broken for a long time.
So did Toshiba and so did Gateway- I still have a Gateway 486 handbook with a pointing stick
However they don't work the same as the IBM trackpoint/nipple/clit mouse, and are inferior enough to give anyone a foul impression of them in general.
There are lots of ways to protect against spoofed replies that are far simpler than DNSSEC. Random ports and only accepting in-bailiwick answers stop a lot of short-range attacks, and RP filtering stops the long-range ones.
If you brought your computer in to Best Buy and said you couldn't play videos- and the techs there saw your naughty pictures in "Your Documents" you took with your wife (or husband), you'd be feeling similarly embaressed.
You could probably expect that the Geek Squad would not upload your pictures to 4chan. You should also be able to count on your hosting provider to show a similar level of discretion.
However you can't say the Best Buy was violating your privacy- not intentionally, not clearly. It seems what happened with your mysql was likely an accident- I see no reason to believe otherwise, and you don't seem to either- you're just grasping around their privacy policy like it somehow matters.
Exactly what kind of attack are you less vulnerable (or invulnerable) to now that you've installed DNSSEC?
DNSSEC doesn't protect against most of the problems using DNS as an attack vector- bugs in BIND and derivatives- DJBDNS has always been secure against this attack.
I paid 6K for a Gateway router, a 608 and a 532, and a couple 4pt D-Link ethernet boards. Direct from Imagestream.
I also got support at 3AM when Sprintlink's core BGP died a number of years ago, and when QWEST switched me from a Juniper to some Cisco with broken MLPPP implementation.
Cisco is a waste of money.
Slashdot ate my url.
http://cr.yp.to/djbdns/dnscache.html
You're right though, my statement was overly broad.
The problem is that DNSSec doesn't do anything. It requires an infrastructure of trustworthy certificate authorities (like Verisign). It's akin to "SSL-encrypt everything and damn the costs".
Of course, it might be useful if DNSSec actually solved any issues that we're having, but it doesn't. DJBDNS is immune to this design flaw in BIND even though this design flaw has been brought up many times before. The real message you should be taking away from this is, and they expect us to trust them?