On 10/05/2010 02:46 PM, Martin Rex wrote:
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.
By most people's definition, it's not "unauthorized impersonation" if
the DNS admin does it
Most people seem to be under the impression that current DNS and TCP/IP
provides such a degree of security that it's "highly improbable" that
there will be an active attack on their server's incoming connections.
I'm not saying this is correct, only that it seems to be the
conventional wisdom.
There may be some organizations that separate the duties of DNS
administration and key generation, but in general I'd think that
organizations operating https servers are more concerned about getting
their domain name stolen than losing control of the PKI chain of trust.
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.
So you seem to be saying that because some currently widely-trusted CAs
will issue a new cert to an attacker able to receive email at the target
domain (e.g. by controlling its DNS as resolved by the attacker's
preferred CA) that nothing which is built on the current PKI is usefully
authenticated. Also, DNS admins must be considered possible attackers.
There's probably a lot of truth in there (or maybe I'm not understanding
you correctly), but it seems like that line of reasoning isn't very
useful. It could be used to support any conclusion.
"PKI cert auth is no more secure than SMTP email" ->
"PKI cert auth is no more secure than DNS" ->
"https is no more secure than DNS" ->
"no point in using HTTPS authentication" ->
"no point in using HTTPS encryption" ->
"we should all give up and go home".
No doubt I feel like that some days.
Let's keep in mind the goal of bootstrapping whatever the current system
is to a higher level the security and efficiency for everyone.
Considering where we are now, this is probably an achievable goal.
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.
Is this the old security - ease of use tradeoff?
Is the solution to increase the cost and difficulty of setting up an
authenticated server? If so, how much will it take?
I'm extremely skeptical of any system which purports to enable "opt-in"
authentication. An attacker can usually just opt-out.
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.
This doesn't seem like a significant factor to me.
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.
Rumor has it that money talks with these CAs. Some will even sell you
the right to issue certs for other domains (i.e., your very own sub-CA)
for the right price.
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?
Well, when you put it that way...
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,
Is there another type of impersonation attack on TCP port 443? I think
I'm not understanding what you're saying here.
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.
Again, it doesn't make sense to me that the security model for
protecting TCP port 443 should be optimized to allow for untrusted
DNS/DNSSEC admins. But I can't tell if we're agreeing on this or not.
- Marsh
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
