Re: https at ietf.org
Phillip Hallam-Baker <hallam@gmail.com> Tue, 10 December 2013 00:23 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6141AD986 for <ietf@ietfa.amsl.com>; Mon, 9 Dec 2013 16:23:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvPdofm0L4Q0 for <ietf@ietfa.amsl.com>; Mon, 9 Dec 2013 16:23:06 -0800 (PST)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1411ABBB1 for <ietf@ietf.org>; Mon, 9 Dec 2013 16:23:05 -0800 (PST)
Received: by mail-wg0-f49.google.com with SMTP id x12so4147259wgg.28 for <ietf@ietf.org>; Mon, 09 Dec 2013 16:23:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HpSRcKjleZpZP4q0DyNUqO1+bFg62lVsTRK1N8NeDZ8=; b=ncqYy0uRWMO1sm/wgvUJAOyMnMtuxm1+aTluwiKuRrQ4zB9soV8z9r8Om1jc+SfANm yQLIFNoAQShVu3ugMpd2k2JnwBGaeELQHbEIrE/+/oyuHFMqh12qJa7vQbzHQDR71XRC p7YoQq5G+B0Lbs+K4FNVrbgPIHpJAh9x/5wtD/KqXofTpVt4W1/AJqlrgzEzISbBAlkX oJcbiIMuottLo/WszReyafE3VA4uGt8gkPpbOGa9NnD24myvF2SVDp67zCUTKuLvcS/A U2Eb14Vl3k1UktVtUAqLZ+mdqXEp0nzcQ/Bvlg40c6gP0Q3gMuU+XTcauSNd8MnVVay8 hrlw==
MIME-Version: 1.0
X-Received: by 10.180.108.97 with SMTP id hj1mr16517056wib.59.1386634980496; Mon, 09 Dec 2013 16:23:00 -0800 (PST)
Received: by 10.194.243.136 with HTTP; Mon, 9 Dec 2013 16:23:00 -0800 (PST)
In-Reply-To: <52A64A1A.2020000@dougbarton.us>
References: <20131125180608.55454.qmail@joyce.lan> <E5836934-317D-4E73-80CC-B8847047852A@virtualized.org> <CAMm+LwhXb6uYJLie1FmJE34aC0EO39_t7331X1O0iD=-gmSEvw@mail.gmail.com> <38B94CB1-C62A-4BAC-85D4-B08FB7315CE9@virtualized.org> <CAMm+LwhF5-nEdM0Rjh1XtK1X=_xo6GkqPnZgfGaCEJ19g8ULrg@mail.gmail.com> <52A176E0.1050708@dougbarton.us> <CAMm+LwiH=1446tXZLKxUyz+jpMHy573aAd5zg1_+Z4kEbVc33A@mail.gmail.com> <52A52972.3020601@dougbarton.us> <CAMm+LwiHwKkK1C7K+DG-LTBS=Edsn=AjH5hCe+9LOukVZbPjmQ@mail.gmail.com> <52A64A1A.2020000@dougbarton.us>
Date: Mon, 09 Dec 2013 19:23:00 -0500
Message-ID: <CAMm+LwgptxAAmCxqP9g8-+EOjwapwb2PJjVvvSe=N6A79WZqXA@mail.gmail.com>
Subject: Re: https at ietf.org
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Doug Barton <dougb@dougbarton.us>
Content-Type: multipart/alternative; boundary="e89a8f3bafef721d4d04ed231d70"
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 00:23:09 -0000
On Mon, Dec 9, 2013 at 5:54 PM, Doug Barton <dougb@dougbarton.us> wrote: > On 12/08/2013 09:41 PM, Phillip Hallam-Baker wrote: > >> >> >> >> On Sun, Dec 8, 2013 at 9:22 PM, Doug Barton <dougb@dougbarton.us >> <mailto:dougb@dougbarton.us>> wrote: >> >> On 12/08/2013 10:21 AM, Phillip Hallam-Baker wrote: >> >> As I pointed out, what I was objecting to was yet another >> iteration of >> someone asserting that the DNSSEC PKI is different from the CA >> system in >> a way that it is not actually different. >> >> So I don't have to fix DNSSEC, all I need to fix here is to have >> David >> and others stop making claims for the protocol that are not >> supported by >> evidence. >> >> >> Um, no. What you originally asserted was that the root was >> vulnerable to being hijacked by an NSL. You have yet to provide any >> evidence of that, and when confronted by evidence to the contrary >> you changed the subject. >> >> So leaving aside the fine points of PKI and how they do or do not >> relate to the root, do you have _any_ evidence to support your >> original assertion? >> >> >> What I said was that any root management is vulnerable to government >> coercion. And that is still obviously true. >> > > So your proof consists of, "Of course I'm right?" No it consists of the argument that followed but you chose to respond to before you read it. Publishing the legit ceremonies might provide some additional >> transparency but does not prevent an illegitimate ceremony being inserted. >> > > Theoretically that's true, sure. But the real question is what practical > benefit would it have for the coercer? Again I'm asking for you to outline > the attack you have in mind in detail. Same as for CA PKI, they can make use of the bogus cert in some closed network and hope that the network does not reach ground truth and discover the attack. There is however another important attack that is unique to DNSSEC which is a denial of signature attack. In the CA system you can always choose another CA. So a legitimate signing request will always be satisfied by some CA in some jurisdiction. The risk in DNSSEC is that the ICANN root signer is coerced publicly to refuse to sign some domain. Congress has the power to pass legislation and a future president might claim that they already have the power. It is not a threat right now because the cost of switching from the ICANN root is small. But it is a risk that should cause concern and there are steps that would mitigate it. The biggest problem is that it makes ICANN too attractive as a takeover target. The point at which it would become an issue is when there are embedded devices that are verifying DNSSEC chains that are not able to accept a root key update. Enabling a root key update is one possible solution but it creates a new set of risks. People can argue that 50 CAs is too many but one CA is too few unless you are running it for yourself alone. There are several possible solutions possible but they all come down to diffusing the trust at the very apex of the DNS so that no party is able to unilaterally defect. The only real control is that any attack leaves irrefutable evidence and >> only a government has the ability to mount such an attack. The idea that >> the NSA or FBI would take such a step in the case of the DNS is >> ridiculous, it would be tantamount to a treaty violation. But the idea >> that they would take similar action against a US based CA or browser >> provider is equally ridiculous. >> > > Sorry, I don't understand most of what you wrote in the paragraph above. > It sounds interesting though. :) The point is that the work that Ben Laurie and others have done on Certificate Transparency is just as applicable for DANE Certs. -- Website: http://hallambaker.com/
- Re: https at ietf.org Eric Burger
- https at ietf.org Tim Bray
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org David Morris
- Re: https at ietf.org Paul Wouters
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Dean Willis
- Re: https at ietf.org Tim Bray
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org Hector Santos
- Re: https at ietf.org Marco Davids (Prive)
- Re: https at ietf.org Hector Santos
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Yoav Nir
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org Eric Burger
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org Thiago Marinello
- Re: https at ietf.org Bjoern Hoehrmann
- Re: https at ietf.org John C Klensin
- Re: https at ietf.org John C Klensin
- Re: https at ietf.org Ted Lemon
- authentication without https (was Re: https at ie… Dave Crocker
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org ned+ietf
- Re: authentication without https (was Re: https a… Ted Lemon
- Re: https at ietf.org MAISONNEUVE, JULIEN (JULIEN)
- Re: https at ietf.org Eric Burger
- Re: https at ietf.org Marco Davids (Prive)
- Re: https at ietf.org Yoav Nir
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Carsten Bormann
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Carsten Bormann
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org t.p.
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Arturo Servin
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Noel Chiappa
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org Chris Inacio
- Re: https at ietf.org Noel Chiappa
- Re: https at ietf.org Tim Bray
- Re: https at ietf.org Tim Bray
- Re: https at ietf.org Yoav Nir
- Re: https at ietf.org t.p.
- Re: https at ietf.org Noel Chiappa
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Chris Inacio
- Re: https at ietf.org Martin Rex
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Martin Rex
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Douglas Otis
- Re: https at ietf.org Pranesh Prakash
- Re: https at ietf.org Pranesh Prakash
- Re: https at ietf.org Martin Rex
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org John R Levine
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Eric Burger
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Joe Abley
- Coercion S Moonesamy
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org John Levine
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Michael Richardson
- Reconstruct the key S Moonesamy
- Re: https at ietf.org Randy Bush
- Re: https at ietf.org Randy Bush
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Sean Turner
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Doug Barton
- Re: [IETF] https at ietf.org Warren Kumari
- Re: [IETF] https at ietf.org Michael Richardson
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org Mark Andrews
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org John C Klensin
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org Douglas Otis