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

Ben Laurie <benl@google.com> Sat, 02 October 2010 20:15 UTC

Return-Path: <benl@google.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 D65FE3A6D62 for <tls@core3.amsl.com>; Sat, 2 Oct 2010 13:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.847
X-Spam-Level:
X-Spam-Status: No, score=-105.847 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 1f--KYfb343E for <tls@core3.amsl.com>; Sat, 2 Oct 2010 13:15:34 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0D7D63A6DB3 for <tls@ietf.org>; Sat, 2 Oct 2010 13:15:31 -0700 (PDT)
Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o92KGM3j019811 for <tls@ietf.org>; Sat, 2 Oct 2010 13:16:22 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1286050583; bh=6uuXUB620KGg3G9vDpjHVr+22Cs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ExxxdZm9FDRowNqzBbDJUL+pxfmyA16ChL5x68oB0iaoI5Cyj2YpFcEfez7LkpWTw l65b7D+r182X+qTlsbKOA==
Received: from qyk34 (qyk34.prod.google.com [10.241.83.162]) by wpaz37.hot.corp.google.com with ESMTP id o92KGJoe025347 for <tls@ietf.org>; Sat, 2 Oct 2010 13:16:22 -0700
Received: by qyk34 with SMTP id 34so1022049qyk.4 for <tls@ietf.org>; Sat, 02 Oct 2010 13:16:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9Iqtx4pY1xBVXOqA3BdW5X8NS6INnk5huWdQ+OUdxr4=; b=vRWovD8LpQIK1iqKcCW/TbDco/9RkozYPs1F93ten8Vufy5iIgh7u+AqQ+P4sYXJAB VfV4Tw4w9VSfsiEoc3rA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oC+jvEs+1m+3tBbQ1gL8oNeyCVUvyTHzI7Y/1j9HSSrkJO6REHLDZdJFaOHOvrDbuG MDxhSOd9XsLmmnKoaPHQ==
MIME-Version: 1.0
Received: by 10.220.34.142 with SMTP id l14mr1873460vcd.83.1286050579493; Sat, 02 Oct 2010 13:16:19 -0700 (PDT)
Received: by 10.220.201.9 with HTTP; Sat, 2 Oct 2010 13:16:19 -0700 (PDT)
In-Reply-To: <AANLkTi=cD1E=QoD3uRyhHyd6bUSgd9_ibgdM5iy1+9TR@mail.gmail.com>
References: <AANLkTinRWJZr7huuG+Ovh3sCCUnVZAghggAzmq7g6ERx@mail.gmail.com> <1285970705.1984.136.camel@mattlaptop2.local> <AANLkTi=cD1E=QoD3uRyhHyd6bUSgd9_ibgdM5iy1+9TR@mail.gmail.com>
Date: Sat, 2 Oct 2010 13:16:19 -0700
Message-ID: <AANLkTimtc1aT0r+oTJYpjixTSiE+gwpORszjPYz7y7PE@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: dnsop@ietf.org, saag@ietf.org, tls@ietf.org, pkix@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: Sat, 02 Oct 2010 20:15:36 -0000

On 1 October 2010 16:15, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
>
> On Fri, Oct 1, 2010 at 6:05 PM, Matt McCutchen <matt@mattmccutchen.net>
> wrote:
>>
>> On Fri, 2010-10-01 at 11:29 -0400, Phillip Hallam-Baker wrote:
>> > In particular I am very concerned about the particular approach being
>> > taken to security policy. What the proposers are attempting to do is
>> > to create a mechanism that allows a site that only uses one particular
>> > high assurance CA to 'protect' themselves against SSL certificates
>> > being issued by low assurance CAs.
>> >
>> > As such, this is an objective I approve of and is one that I would
>> > like to see supported in a generalized security policy. It should be
>> > possible for a site to make security policy statements of the form
>> > 'all valid PKIX certs for example.com have cert X in the validation
>> > path'.
>> >
>> > What I object to is the approach being taken which is to use DNSSEC to
>> > replace PKIX certificate validation entirely.
>>
>> Realize that I, and I would guess many other site admins, want precisely
>> that.  PKIX is complicated, whereas once I have a DNSSEC signed zone,
>> placing my TLS server's certificate in the zone and knowing that clients
>> will accept that certificate and no other could hardly be simpler.  And
>> why shouldn't I be allowed to do it?  I have complete authority over my
>> zone (even for the most part in the present public CA system).  Nobody
>> gave PKIX a monopoly on the determination of certificate acceptability.
>>
>> We could support a more general scheme in which positive assurance is
>> separate from restrictions, but don't be surprised when a significant
>> fraction of sites use it to effectively "replace PKIX certificate
>> validation".
>>
>
> The problem with that approach is that the attacker now has two
> infrastructures that they can attack rather than just one.

If I deploy the DNS solution, stating that DNS is authoritative, then
my attack surface now excludes all CAs. How is that an increase in
attack surface?

Contrast with today's situation, where my attack surface is increased
on a regular basis by the introduction of new CAs, without any
consultation with me at all.

> You are increasing your attack surface, not reducing and simplifying it as
> you might imagine.
>
>>
>> > Worse still, the proponents refuse to allow any method of shutting
>> > this system off. So if I have a site where I want to use DNSSEC
>> > validated certificates on the mail server, deployment is going to
>> > impact my Web server.
>>
>> Yes, there should be a way to make the exclusivity optional, but there
>> may be better ways to solve the problem you cited, such as placing the
>> DNSSEC certificate at the SRVName for the mail server.
>
>
> Regardless, I believe that the PKIX and TLS groups should be aware that this
> is the change that has been implemented in code and is being proposed before
> the WG is chartered.
> There are much better ways to express the trust restriction semantics. I do
> not see why the ability to express statements concerning your trust roots
> needs to require deployment of a completely different mechanism and trust
> path for the end entity keys.
>
> For example, the ESRV mechanism is extensible. So it is possible for a site
> that has their own PKI and root of trust to specify that there has to be a
> trust path that includes that root of trust. Or you could publish a
> fingerprint of a cross cert that has to be involved or you could even state
> that there must be a cert record with the right fingerprint.
>
> --
> Website: http://hallambaker.com/
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>