Re: [therightkey] [dane] DANE and CT

Paul Wouters <paul@nohats.ca> Fri, 16 November 2012 18:50 UTC

Return-Path: <paul@nohats.ca>
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 0B74F21F84CC; Fri, 16 Nov 2012 10:50:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 2m5PaHJRy1JG; Fri, 16 Nov 2012 10:50:18 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2D08D21F84C6; Fri, 16 Nov 2012 10:50:18 -0800 (PST)
Received: by bofh.nohats.ca (Postfix, from userid 500) id F360682B74; Fri, 16 Nov 2012 13:49:26 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D779982B5B; Fri, 16 Nov 2012 13:49:26 -0500 (EST)
Date: Fri, 16 Nov 2012 13:49:26 -0500
From: Paul Wouters <paul@nohats.ca>
To: Ben Laurie <benl@google.com>
In-Reply-To: <CABrd9SQPg+5CJk_Quv3J_kOedd+NeDc2aqregdcbWnZofjb8kg@mail.gmail.com>
Message-ID: <alpine.LFD.2.02.1211161339000.11982@bofh.nohats.ca>
References: <CABrd9SRyv+UerPJBf+gw47nWj3t4ekHRnWsKC0pHcadHV5mvmw@mail.gmail.com> <alpine.LSU.2.00.1211141601220.27013@hermes-1.csi.cam.ac.uk> <CABrd9SQ7mt_DSkVimrJ03K9suXEQzYSc_vZ3qUtGLCiphvRetQ@mail.gmail.com> <alpine.LFD.2.02.1211141124490.4326@bofh.nohats.ca> <CABrd9SSv7vfxOhogGmYSWC8hROyXL_z4TJC8mxNMW-apSg5Y0Q@mail.gmail.com> <alpine.LFD.2.02.1211151501490.17666@bofh.nohats.ca> <CABrd9SQPg+5CJk_Quv3J_kOedd+NeDc2aqregdcbWnZofjb8kg@mail.gmail.com>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: Tony Finch <dot@dotat.at>, therightkey@ietf.org, 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: Fri, 16 Nov 2012 18:50:19 -0000

On Fri, 16 Nov 2012, Ben Laurie wrote:

>> Because there are DNSSEC keys to back the time slots used, and
>> without it, the data can and should be rejected.
>
> This argument is circular: clearly if no-one ever gets control of keys
> for your domain, you don't have a problem. Validity times are
> irrelevant.
>
> If someone does get control, they control validity times, no?

If someone obtains your private keys, there is no need to forge anything
or issue any new certificates, they just run a copy of your private
key/cert on their MITM box. CT can't help you there either. If attackers
get your private DNSSEC keys (which shouldn't even be online, and surely
much harder to obtain compared to the TLS private key) you are lost.

> You have a lot of faith in a mechanism that is not designed to provide
> a globally consistent view. How does DNS prevent bad actors from
> showing local views of the DNS? (Hint: it doesn't).

The root key protects me against that. And the TLD key. Sure, if I'm
using some untrusted national TLD which might be overwriting my parent
NS/DS set, again you are in a no-win situation. Best you can do is
monitor your own zone, and possible carry your own domain's trust
anchors with you. And these same players would simply prevent you from
accessing the CT services as well.

> This is precisely what CT does, and is exactly the value it adds to
> this kind of system.
>
> As for CT vs DANE, it is precisely because DNS does not provide a
> robust infrastructure that DANE cannot be allowed to override CT.

So Diginotar will submit a new cert for me to the CT, and we're back at
square one?

> This
> can be fixed by making DANE use some kind of equivalently strong
> transparency. I agree with others that this is probably better applied
> to DS records than to TLSA records.

While I agree that it won't hurt to log and audit DS records to see if
verisign or the USG really is signing their own records with the root or
.com keys, I still believe those two parts are the most secure players
I know to delegate some trust to. The real weak points of DNSSEC will be
the dns operators of the zones and the registrar webgui's for making
zone changes. In fact, I would probably rather trust the root key, then
most CT audit people - and it would come with less false positives due
to the middle man delays.

Paul