Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

[Martin Rex <[e-mail]>]

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