On Sat, 16 Aug 2008, Ted Lemon wrote: > On Aug 16, 2008, at 4:56 PM, Dean Anderson wrote: > > For example, besides the previously mentioned key rollover > > issue, I understand that DNSSEC also doesn't allow the protocol to be > > changed securely. And we do expect the protocol to be changed. > > As a non-expert in DNSSEC, I have to admit that I am not aware of an > expectation that the protocol will change. Can you expand on this?
I'm also a non-expert on DNSSEC. I take this excerpt from Olaf Kolkman's message of December 1, 2007: as indicating that it will need to change: Begin quote ====================================================== > Please speak up if this change is of concern to you. > If no one speaks up by Dec 7'th I will tell our AD the changes are > fine. So the change is that the basic-4 steps procedure was removed and replaced with text that amounts to "We'll solve this when we get to this". For those who are not up to speed with the issue that is being addressed, the thread causing all this starts here: http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00553.html To me it is clear that the current text postpones dealing with the problem that starts with the premisses in Sam Weiler's observation: "but we aren't (as far as I can tell) requiring that an NSEC3- SHA256-capable resolver also support NSEC3-SHA1" If the requirement to support old algorithms would exist, then the rollover is one that we currently understand. End quote =========================================================== > Also, is there a way to build the protocol so that it can be changed > securely? Hopefully, there is. Though mainly, I think the problem is the hash change problem. > I would think that the way this would happen would be that > the resolver would ask different, or additional, questions. Does the > current protocol preclude that? I suppose not. But changing resolvers repeatedly is a big problem, because you have to support the old resolvers. The zones are quite large with the current records. > > The hype surrounding the Kaminsky report is unjustified. For example, > > one can't steal bank information with this attack, as the mainstream > > press has reported. > > This isn't true, because if I can convince you that a naive user that > he or she is talking to your bank, I can get them to enter their > information into a web page that isn't protected by SSL. > > Alternatively, I can find a server that has a valid SSL cert, crack > it, set up a redirect that sends the user's password through that > server. They wind up doing an SSL-validated transaction that appears > to be completely fine, but is not. Since I've suborned an existing > server, even once the hack is discovered, if it is, it can't be traced > back to me through the SSL cert trust chain. The above attacks aren't dependent on DNS attacks. - If the user is naive and doesn't check that connection is secure and that the certificate belongs to their bank, then they are subject to any number of schemes. - If Mal cracks someone else's server, that server still doesn't have the bank's certificate, and won't have the bank's dns domain, either. So the browser should think that it got the wrong certificate. The user should always check that they have the right certificate and that it verifies correctly. If the user doesn't do that, no amount of DNS security will save them from a variety of phishing or similar-URL/similar-domain attacks. Every browser that I know of allows the user to examine the certificate and its validation. If the user fails to check this, they lose. This thread is quite interesting: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00853.html > > There has been some assertions that SMTP anti-spam security depends > > on DNS security. These schemes don't hold water. In 2003, I showed > > that the information theory result that no communication system can > > be proven free of covert channels implies that no communication > > system can be designed 'spam-free'. > > I think you carry this argument a bit farther than is justified. > It's probably true that no security system can be perfect. Locks > don't keep out determined lock pickers. They certainly don't keep > out people with fire axes. But they do raise the cost of entry. I'll try to keep it pertinent to DNSSEC. In this case, the cost of entry is the botnet, and the cost isn't altered at all by DNSSEC, or by SMTP alteration, micropayments, estamps, SPF, or what have you. Once the computer is controlled by a virus, the attacker has the user's credentials--all of the credentials. Adding more layers of authentication can't change anything. People seem to have a hard time understanding that the virus on their computer is, electronically, _them_. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
