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, 03 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/
- [TLS] Cert Enumeration and Key Assurance With DNS… Phillip Hallam-Baker
- Re: [TLS] Cert Enumeration and Key Assurance With… Ben Laurie
- Re: [TLS] Cert Enumeration and Key Assurance With… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Matt McCutchen
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ben Laurie
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Peter Gutmann
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Phillip Hallam-Baker
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Tony Finch
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Michael StJohns
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Tony Finch
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ralph Holz
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Stephen Farrell
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Geoffrey Keating
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] Cert Enumeration and Key Assurance With… Ondřej Surý
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] Cert Enumeration and Key Assurance With… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Jakob Schlyter
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Michael StJohns
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Andrew Sullivan
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- [TLS] OtherCerts & pinning (Was: Re: [pkix] Cert … Stephen Farrell
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Kemp, David P.
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ralph Holz
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ondřej Surý
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Seth David Schoen
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Stephen Kent
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Paul Hoffman
- Re: [TLS] Cert Enumeration and Key Assurance With… Nicolas Williams
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … Peter Gutmann
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … Yaron Sheffer
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Henry B. Hotz
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … der Mouse
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Carl Wallace
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [DNSOP] [saag] [pkix] Cert Enumeration … Doug Barton
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Bruno Harbulot
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Paul Wouters