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

Marsh Ray <marsh@extendedsubset.com> Wed, 06 October 2010 02:04 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078303A6D27; Tue, 5 Oct 2010 19:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.082
X-Spam-Level:
X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PL6f4oHDsHp; Tue, 5 Oct 2010 19:04:36 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 938193A6C0A; Tue, 5 Oct 2010 19:04:36 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1P3JNv-000AbN-CR; Wed, 06 Oct 2010 02:05:35 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id ECA496018; Wed, 6 Oct 2010 02:05:32 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18A3yYFcT2jzaNQV+n1e3ipTljIWbhA94M=
Message-ID: <4CABD96C.3060007@extendedsubset.com>
Date: Tue, 05 Oct 2010 21:05:32 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: mrex@sap.com
References: <201010051946.o95JkteM009316@fs4113.wdf.sap.corp>
In-Reply-To: <201010051946.o95JkteM009316@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: DPKemp@missi.ncsc.mil, dnsop@ietf.org, saag@ietf.org, pkix@ietf.org, tls@ietf.org
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Oct 2010 02:04:39 -0000

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