I was attempting to refer to the fact you considered the break noteworthy rather than that you were the source, my apologies if that was not clear. I think we do need to change the DNS model. But not necessarily as drastically as DNScurve and not to get rid of caching. I would like to see us create an assumption that a given machine will only use recursive resolution services from a specific trusted source. This in turn requires us to add some features to the protocol as we need to add mechanisms for access control. We also need to make some changes to get around widespread DNS hacks used to support roaming WiFi provision. [Oh we are so not close to being done with deployment here. If turning on DNSSEC means the typical Web surfer cannot get their WiFi access at Panera without reconfiguring their machine then DNSSEC is stone cold dead.] Rather than using the approach in DNScurve, I would want to see something like the following: * When a new machine is brought up the configurer is asked which network they want it to be a part of, identified by a DNS name. This will be the place that the system will use to look for the trusted DNS resolution service. Since I use 8.8.8.8 I would enter 'google.com'. The default could be taken from DHCP * New RR to allow a machine to locate a trusted resolution service for the network and authentication protocols supported. The initial bootstrap could be taken from the DHCP service. * Key agreement mechanism that allows the client to establish a persistent binding represented by a kerberos style ticket * Packet encapsulation mechanism that enables a kerberos style ticket to be entered into client request packets. The situation we have at the moment is similar to the one you get with a large tub of lego. We have all the pieces we need, but they are mixed in with a much larger amount of stuff that we don't really need. Telling people they can build this from IPSEC, Kerberos and SASL is like telling people they can do brain surgery if they read some wikipedia articles. On Wed, Feb 24, 2010 at 2:29 PM, Steven M. Bellovin <smb@xxxxxxxxxxxxxxx> wrote: > On Wed, 24 Feb 2010 12:44:10 -0500 > Phillip Hallam-Baker <hallam@xxxxxxxxx> wrote: > >> The problem here is not that you might infringe the patent, the >> problem is that if a patent suit is brought against you, it will cost >> a minimum of about $5 million to defend. Just to get to the point of >> having an opinion on the matter you would have to engage a competent >> expert witness who was willing to work on patent stuff rather than >> building stuff. Then they have to do maybe a months work on research >> and explain the results to a group of lawyers. You are going to have >> five or more people and rack up several thousand hours at lawyer >> rates. >> >> Those costs buy a lot of crypto accelerator boards. >> >> I kept trying to explain this situation to the various people who >> tried to sell their 'efficient CRL' hacks. Even if your system is the >> greatest ever and you give it to me for free, it will cost more to >> work out if it is legally safe than it costs to solve the problem with >> raw CPU power. >> >> >> If the 512 byte limit really is a problem, then the logical answer >> would be to use DSA-SHA256 since the signatures generated in DSA are >> not a function of the key size. DSA also allows for offline >> calculation of the signature data which would address performance >> issues for companies like Akamai. >> >> There are also reasons to beware of DSA. Steve Bellovin pointed out >> that if the random number generator is bad the private key can leak >> out. But RSA is not without similar issues, companies that can't >> generate a good random seed for DSA will probably not create secure >> keypairs for RSA either. >> > I've pointed it out in the IETF, but I'm certainly not the one who came > up with that observation in the first place; please do not give me > credit for other folks' work. > > More on-topic: unless I'm very much mistaken, DNScurve relies on > transmission security rather than object security; in turn, that > requires a pretty fundamental change in how the DNS works. (Well, not > completely, but you wouldn't gain any security benefit against most of > the threats from cache contamination if you didn't change it.) Maybe > the DNS can work that way or should work that way -- but I haven't seen > any analysis to show that the load is manageable without caching and > with lots of banging on the authoritative servers. > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf