Richard L. Barnes wrote: > > >>> If a system is going to be robust in practice it has to take account > >>> of all possible sources of error including administrative incompetence > >>> and user error. > >> > >> I'm curious: where do you draw the line? Should routing system security > >> be included? Email security (since many transactions relating to DNS > >> zone administration occur via email)? Telephone? Etc. > >> > >>> Security that only looks at malice is brittle security. > >> > >> Security that looks at 'all possible sources of error' seems to me > >> to be a halting state problem > > > > Drawing a line amounts to sticking your head in the sand. > > > > A chain is only as strong as its weakest link, and aside from > > wanna-bees, determined attackers are *not* going to attack the > > strong pieces of the technology, but turn the weak parts or > > the links between. > > > > Using DNS names for authentication is the folly here. If we believe > > in using DNS names for authentication, then we need to fix *all* > > parts of the technology, including the adminitrative procedures > > for managing/delegating DNS names. > > Ok, what names *should* we be using? > Maybe we should use names that people claim by presenting > their drivers' licenses? > <http://dmv.ca.gov/pubs/newsrel/newsrel11/2011_26.htm> > Passports? > <http://www.usimmigration.com/selling-fake-passports.html> > > Can you point to an identity system that doesn't have > layer-9 vulnerabilities?
The task of having to fix *all* parts of the chosen technology will be independent from the identity system that we choose. Commercial CAs seem to have some amount of success in convincing businesses that EV-certs are more trustworthy than DV-certs, and one of the reasons might be that their failure mode is not tied to the DNS registration/administration procedures alone. (i.e. a combination of two identity systems). I'm not aware of any secure identity system (if one existed, everyone would be using it and we would not constantly be inventing new ones). The *existing* security of those that currently exists are based on a trade-off resulting from a risk assessment, trying to keep the cost of breaking it above the value of the protection, so it is effectively good-enough to be economically unattractive to attack (Coasean Floor), combined with the hope, that the number of attacker who do are not economically motivated, is so small that they can be neglected. Think of counterfeiting of cash money. There is no such thing as a perfect counterfeiting protection. Protections are "good enough" when the economic cost of counterfeiting a certain unit of cash money is higher than economic value of that unit of cash money itself. > > Domain names are names like any other name, except they have some > nice features: Hierarchical storage and you can use them to look > stuff up. ISTM that this group will have a win if they can come > up with a good way to authenticate domain names, possibly patching > over some of the layer-9 weaknesses. DNS, and the adminstrative procedures for registration/delegation/management was not designed with a high degree of trustworthiness in mind. Personally, I strongly believe that DNS should remain fast, scalable and affordable. Trying to make DNS much more trustworthy would mean a price hike of the fees of more than a magnitude for everybody. I can imagine that some companies in the DNS business would appreciate the new business opportunity to multiply their revenues and rake in huge amounts of money. But charging a magnitude higher fees for hundreds of millions of domains in order to make DNS-based authentication more trustworthy for some ten thousands of domains where it is actually needed bears some resemblance with scam. I strongly believe that some level of "pinning" information from previous authentication and using it to verify successor authentications would significantly reduce the attack surface without requiring redesign of the entire infrastructure. -Martin _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
