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