Re: https at ietf.org
Mark Andrews <marka@isc.org> Tue, 10 December 2013 00:53 UTC
Return-Path: <marka@isc.org>
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 912321AE042 for <ietf@ietfa.amsl.com>; Mon, 9 Dec 2013 16:53:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 k-TSBXjqDeY5 for <ietf@ietfa.amsl.com>; Mon, 9 Dec 2013 16:53:20 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 06AC61AE02A for <ietf@ietf.org>; Mon, 9 Dec 2013 16:53:20 -0800 (PST)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id DC0DCC94B3; Tue, 10 Dec 2013 00:53:01 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1386636795; bh=n1NU+IU9shAIRhfnQG3+s3OTar5EpwLOaDy5e5lVuZY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=rY93tUZAOjWiqY5lPmU+gmQGPnUrbRiE/KqIWiC9gN7M6Yl7oR2NbxTbg4gWWS30a 7fMdxAG+evMY6xP4sKzD/y3UEnnA5oq/2Tm7UJfttNrIAw0qC1/Xc22x6FukqHmmNT DtG86uQvxXLONplqOv9uHlLqy1q//+ezouXRempk=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 10 Dec 2013 00:53:01 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9E32A160459; Tue, 10 Dec 2013 01:01:15 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 4709B160446; Tue, 10 Dec 2013 01:01:15 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 169F9B6E2F1; Tue, 10 Dec 2013 11:52:59 +1100 (EST)
To: Phillip Hallam-Baker <hallam@gmail.com>
From: Mark Andrews <marka@isc.org>
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> <CAMm+LwgptxAAmCxqP9g8-+EOjwapwb2PJjVvvSe=N6A79WZqXA@mail.gmail.com>
Subject: Re: https at ietf.org
In-reply-to: Your message of "Mon, 09 Dec 2013 19:23:00 -0500." <CAMm+LwgptxAAmCxqP9g8-+EOjwapwb2PJjVvvSe=N6A79WZqXA@mail.gmail.com>
Date: Tue, 10 Dec 2013 11:52:58 +1100
Message-Id: <20131210005259.169F9B6E2F1@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
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:53:22 -0000
In message <CAMm+LwgptxAAmCxqP9g8-+EOjwapwb2PJjVvvSe=N6A79WZqXA@mail.gmail.com> , Phillip Hallam-Baker writes: > 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. Which is trivial to work around by adding a TA for the zone in question. Remember the zone publishes the DNSKEY and DNSSEC is designed to work with islands of trust. RFC 5011 give a crude mechanism for following DNSKEY changes. For a similar reason removal of TLD's can't happen as people can still graft on namespace and establish TA's for the grafted on namespace. > 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/ > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- 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