Re: [therightkey] [dane] DANE and CT

Phillip Hallam-Baker <hallam@gmail.com> Thu, 15 November 2012 13:02 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8B821F88E0; Thu, 15 Nov 2012 05:02:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.237
X-Spam-Level:
X-Spam-Status: No, score=-4.237 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFtW-injI08v; Thu, 15 Nov 2012 05:02:06 -0800 (PST)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33E7721F88D4; Thu, 15 Nov 2012 05:02:06 -0800 (PST)
Received: by mail-oa0-f44.google.com with SMTP id n5so1676685oag.31 for <multiple recipients>; Thu, 15 Nov 2012 05:02:05 -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=f2HC2wPzdPE8COkfgKDDQS9YFTBNN8ou70CmYFGivFk=; b=q6HbvIdWM6owz6bUflnaK1uLDQ2amg+e+xPIH2awssG8rFQ0d/UppcoYTLKGFpDoHh +BCYpS73a/+wLL0NNv4QDrMvNP2YQf+uf+LWyJsYGVoYRXzs7DPTZWSkyPwxyLcjPsJt yjtjZm+5nue8BQS+4pX8eNha49WylTOqrrgmynQcVIUkfrtS6vR5GnZLpvsEWgmO6WAg 1dLZpwJOUS70l10hr9XNHkNKAuZ1MTscYqSc2OddEnQqACPtFVAYFkrgwSpjsvbcol67 +UtJOKaUiASTjwm0GPDcTbRWgTcESKa9vs1lEfyS+PSpoe1B9LbReeVLgth4Uo/Y8nLR MMaw==
MIME-Version: 1.0
Received: by 10.60.26.38 with SMTP id i6mr769234oeg.23.1352984525441; Thu, 15 Nov 2012 05:02:05 -0800 (PST)
Received: by 10.76.27.103 with HTTP; Thu, 15 Nov 2012 05:02:04 -0800 (PST)
In-Reply-To: <alpine.LSU.2.00.1211141601220.27013@hermes-1.csi.cam.ac.uk>
References: <CABrd9SRyv+UerPJBf+gw47nWj3t4ekHRnWsKC0pHcadHV5mvmw@mail.gmail.com> <alpine.LSU.2.00.1211141601220.27013@hermes-1.csi.cam.ac.uk>
Date: Thu, 15 Nov 2012 08:02:04 -0500
Message-ID: <CAMm+Lwgy-vtd+xk87kY1bDFccT8MTFuJ2d3mLKmyo91gmM-FvQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Tony Finch <dot@dotat.at>
Content-Type: multipart/alternative; boundary="e89a8fb2007c068a1004ce884299"
Cc: therightkey@ietf.org, Ben Laurie <benl@google.com>, IETF DANE WG list <dane@ietf.org>
Subject: Re: [therightkey] [dane] DANE and CT
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 13:02:07 -0000

On Wed, Nov 14, 2012 at 11:02 AM, Tony Finch <dot@dotat.at> wrote:

> Ben Laurie <benl@google.com> wrote:
>
> > At the CT BoF the question was raised: what about DANE?
> >
> > Which is a good question. So, I think Google is prepared to
> > contemplate running a CT log for DANE, but this leaves some
> > questions...
>
> What problem would CT for DANE be aiming to fix?
>

I see a number of issues that need fixing:

1) Domain hijacking

DANE certificates are only as secure as the DNS names they are attached to.
DNS hijacking occurs at a rate well in excess of 10,000 names a year and is
probably much much higher if we could get better numbers.

At present the DNS name owner (and it is the owner, regardless of what
idiot lawyers claim) has to rely on their registrar to be competent and on
the processes at the registry and to a certain extent on the honesty of
other registrars. This whole area is essentially opaque, there is no
documentation for most of the processes on which businesses are forced to
rely.


2) Root jacking

Russia and China are just not going to be recognizing the ICANN roots
dudes. They have been telling everyone who will listen that they are going
to fork the root and they have a big enough fraction of the population of
the planet to make it stick.

So people can do the ostrich head in the sand thing or they can anticipate
this attack and think about ways to neutralize it.


3) Demonstrate continuity

In the case that a DNS name changes hands I do not necessarily want to be
sending the new information the confidential data I would have sent the old
one. Lacking the ability to establish an external validation of the source,
this means I am much more interested in determining the lineage of
credentials.


Or it could just be that the DANE people have created an absolutely perfect
system that is beyond any possible reproach and the fact that nobody seems
to be implementing it beyond limited scale trials and plugins is due to the
inability of everyone else to fully appreciate their awesomeness.


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