Phillip Hallam-Baker wrote: > > David P. Kemp wrote: > > > > For the DNS/PKI case, if A is an IP address for a dnsname and B is a > > public key for a dnsname, then it is necessary to attack the sources of > > A and B in order to successfully spoof a named server. If A and B come > > from the same system (e.g., DNS) it is necessary to attack only that > > system. If they come from different systems (DNS and PKI) then it is > > necessary to attack both. Attacking only one may cause an availability > > failure, but not an integrity failure. > > When I originally looked at this scheme I thought that it was intended to > reduce the attack surface in the manner you describe. > > Clearly if you have two controls, A and B and BOTH must be compromised, the > system is less likely to be compromised than either A or B.
The DNS admin that controls A can always get a perfectly valid certificate B issued and successfully impersonate all services offered on servers in his DNS domain. Because of this characteristic of the TLS PKI, it doesn't matter how much scrutiny the CAs apply, if you can not trust the DNS admin, you loose. Requiring the involvement of a pre-trusted commercial CA makes it less attractive to DNS admins to abuse their position and harder for attackers that manage to modify DNS records of DNSSEC signed zones to impersonate servers in that DNS zone. Obtaining CA-signed server certs may require "official procurement", so the issuance of the server certs goes on record at the issuing CA and the domain owners procurement. This could serve as a deterrent for outsourced DNS services or unhappy DNS admins. > > But the design approach taken in the Hoffman et. al. proposal is that > publication of a DNSSEC assurance for a cert disables verification on the > PKIX chain unless the 'preferences' flag is set. This flag will be buried in > a base64 encoded sub-field encoding. What is the alternative? I'm constantly hearing some folks that want to obtain DNSname-constrained organizational CA-certs signed under one of the pre-configured trust anchors so that their (DNS) admin can issue server certs without involvement of commercial CAs. Such CA-certs will probably sell at a significant premium. Should the IETF really define TLS technology in a fashion where everyone will have to buy out of slavery from a commercial CA oligopoly at a significant premium for every DNS domain one operates? It is a "trade-off", to hold the whole world hostage to the CA oligopoly in order to keep the initial investment (the "Coasean floor"[*]) high for only one specific impersonation attack, but I'm not convinced that this particular approach is the the best solution or the only solution and that the benefit is worth the cost. I could imagine that it appeals to top-level management, because they do not like to worry about outsourcing stuff (like DNS administration) or worry about making employees (like DNS admins) unhappy. -Martin [*] There was an article about "Coasean floor" in Bruce Schneiers Dec-2008 Cryptogram http://www.schneier.com/crypto-gram-0812.html#7 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
