Re: https at ietf.org

Phillip Hallam-Baker <hallam@gmail.com> Tue, 10 December 2013 03:39 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 8D1C51AE169 for <ietf@ietfa.amsl.com>; Mon, 9 Dec 2013 19:39:44 -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 CydiRmSTC2rP for <ietf@ietfa.amsl.com>; Mon, 9 Dec 2013 19:39:41 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 831711AE168 for <ietf@ietf.org>; Mon, 9 Dec 2013 19:39:41 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hn9so4725750wib.1 for <ietf@ietf.org>; Mon, 09 Dec 2013 19:39:36 -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=cEj5tW8MQA/62AJaTLwj+0Iw66Xpr29D+5x/xUjRmQo=; b=v0q6OQqE7VpPWHg+RADsIGDo1TPVjuyrWxRwx/V4dtw70sPZ7T5RWznMPz4hB9hARa eAutMhbp0bkC1sPx+Dc2DsaVXsvFahFYENt97jpECnAe+ThmiQGPB1RyhdGGPmyeS5Uk s/2RTJyKggfWpTUULhcKyj/oIfk36D+SMFsy32OGpJyPJiCAz4mfibZvqDWuzQSCgsG4 N1gLp/XLILCtYDzJ7iwcjkBPuypbwE76S2dyktBgNvtaUO5LYS+prEd0PQDu25TH2n9C zfgE1ZKvDCMjuTJ3tc7NfMTBv2wcmLUyQ1OAAUKGG4d8uVY6pOxj18eJTwS6Hb0txb0t 6dIw==
MIME-Version: 1.0
X-Received: by 10.194.84.72 with SMTP id w8mr9177009wjy.55.1386646776063; Mon, 09 Dec 2013 19:39:36 -0800 (PST)
Received: by 10.194.243.136 with HTTP; Mon, 9 Dec 2013 19:39:35 -0800 (PST)
In-Reply-To: <20131210005259.169F9B6E2F1@rock.dv.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> <20131210005259.169F9B6E2F1@rock.dv.isc.org>
Date: Mon, 09 Dec 2013 22:39:35 -0500
Message-ID: <CAMm+LwhyXaOP8k8tZ6-cPrmmyXXjfgO=Jr5Jyf4S+WAZus1CWQ@mail.gmail.com>
Subject: Re: https at ietf.org
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary="047d7bea40ba84313804ed25dce0"
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 03:39:44 -0000

On Mon, Dec 9, 2013 at 7:52 PM, Mark Andrews <marka@isc.org> wrote:

>
> 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 trivial to fix when the validation is taking place in a service in
the cloud (aka a resolver).

Rather less easy to do if people drink the DANE cool-aid and do the job at
the end point.

Now you can take this point as either arguing against doing DANE or
considering the risk and deploying the appropriate control. But you do have
to consider it.


What you are in effect asserting is that the resolver providers are the
apex of the trust chain and so there is a diffuse trust surface rather than
a sharp point. Which is true when the validation takes place in the
resolver.

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