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

Phillip Hallam-Baker <hallam@gmail.com> Sun, 03 October 2010 15:13 UTC

Return-Path: <hallam@gmail.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 4A11E3A6CE1; Sun, 3 Oct 2010 08:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.414
X-Spam-Level:
X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 6D8RsKsaC8TE; Sun, 3 Oct 2010 08:13:32 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 239C53A6CD8; Sun, 3 Oct 2010 08:13:30 -0700 (PDT)
Received: by wyi11 with SMTP id 11so4996012wyi.31 for <multiple recipients>; Sun, 03 Oct 2010 08:14:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=KcCRwUdhKfFk38z3+dN7361oBbuTFWY+e52RJqx+GAk=; b=XG/eRqs6wv8hHUeSLbTIwWKs0gLOfMD/NKqzqAX5xveT4D03l8Q3vM2zSQ8qIEyzxj YJBGP4gztobM9tOODN1lpNIZ/44DRiASws6ArKurZuO0a2Q8sOCiOpRi3VzoNCLjCj4/ ULcou8iLgsCF5c+m1CbpV9eMmzI/5X/Y/EvNA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QpzJQSIIG8LoXGSH0Nrk6gZtw9tt/MbS1St5F3cHrvgpyue/7Qy3Gci4HKy5BxyFdR y0PHFuGeNbKw2KovYUFNrHNpjIRFY3LwKEHFWbM9IN1jAyChdq5eXO9P+nJ8QApHfLSO O4NveynSccvCiAHW38giEbbbryprjm0o4fyQU=
MIME-Version: 1.0
Received: by 10.216.59.131 with SMTP id s3mr6605073wec.71.1286118863280; Sun, 03 Oct 2010 08:14:23 -0700 (PDT)
Received: by 10.216.166.9 with HTTP; Sun, 3 Oct 2010 08:14:23 -0700 (PDT)
In-Reply-To: <B7C7EE71-D872-403F-A0F4-7622BABC4C3D@dotat.at>
References: <AANLkTinRWJZr7huuG+Ovh3sCCUnVZAghggAzmq7g6ERx@mail.gmail.com> <1285970705.1984.136.camel@mattlaptop2.local> <AANLkTi=cD1E=QoD3uRyhHyd6bUSgd9_ibgdM5iy1+9TR@mail.gmail.com> <AANLkTimtc1aT0r+oTJYpjixTSiE+gwpORszjPYz7y7PE@mail.gmail.com> <4CA7E120.6080701@extendedsubset.com> <B7C7EE71-D872-403F-A0F4-7622BABC4C3D@dotat.at>
Date: Sun, 3 Oct 2010 11:14:23 -0400
Message-ID: <AANLkTinUAM9t29r+Y9fBhXHV-TWouS3hEs0N_Ai_z=Ey@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Tony Finch <dot@dotat.at>
Content-Type: multipart/alternative; boundary=000e0cd72042fc20c80491b7e1e2
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, "saag@ietf.org" <saag@ietf.org>, "pkix@ietf.org" <pkix@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [DNSOP] [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: Sun, 03 Oct 2010 15:13:34 -0000

If the problem is the lack of checks and balances, the solution should be to
introduce checks and balances.

Moving from a market based solution with multiple CAs to a monopoly with one
trust provider does not help at all. It makes the situation much worse
because there is now no possibility of choice in the future.


This type of decision needs to be taken in the open with the proposers
clearly stating what they are about. The proposed charter as written
misleads the reader into thinking that what is being proposed is to use the
DNSSEC to provide one ADDITIONAL trust provider.

What is actually being proposed is to replace the fifteen year established
system of CAs with a new scheme starting in November.


If you read through the KEYASSURE archives, you will find that whenever the
proposers of this scheme are asked questions that they avoid answering them.
Most often they claim not to understand what is being asked.

I really don't think that we want to replace the existing infrastructure a
new PKI designed by people who claim not to understand the issues involved.
As the proposers of this scheme have done repeatedly.

This whole thing is being hurried through as if the proposers know that if
people actually stop and look at what is really being proposed that they
know the whole proposal will collapse.


Before we go any further with this, I want full disclosure. I want to know
the full extent of what is being proposed. I also want to know anything else
that might affect the consideration of this proposal.

The reaction to asking legitimate security questions has been really rather
awful. Whenever I ask a question, Paul Hoffman has immediately popped up to
claim that nobody can understand it, apparently in an attempt to divert
examination of the question into a flame war.

I do not think it is legitimate for a group of people to bully and threaten
away those of contrary views and then declare that they have achieved
'consensus'. That is the way Trotskyites take over political parties, they
call it 'entryism'.


On Sun, Oct 3, 2010 at 8:15 AM, Tony Finch <dot@dotat.at> wrote:

> On 3 Oct 2010, at 02:49, Marsh Ray <marsh@extendedsubset.com> wrote:
> >
> > In the meantime, we'd end up with the DNS root effectively having the
> power of yet another CA. Except that it's not, because the various arms of
> ICANN and VeriSign/Symantec are probably already trusted many times over.
>
> I agree with your points about the difficulty of rolling out DNSSEC key
> assurance and its coexistence with PKIX.
>
> But the above is a bit off-base, because the DNS has a lot of structural
> constraints that make it weaker than a CA. Although in theory the root zone
> operators could steal any arbitrary name, the organisational checks and
> balances prevent that. CAs have no significant external checks and balances.
> For example they don't have the equivalent of whois that allows third
> parties to check who has been issued a certificate for a particular name.
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
>
>


-- 
Website: http://hallambaker.com/