Re: [therightkey] [dane] DANE and CT

Paul Wouters <paul@nohats.ca> Thu, 15 November 2012 20:11 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 ADE0821F850B; Thu, 15 Nov 2012 12:11:41 -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 k29YbIooC63y; Thu, 15 Nov 2012 12:11:41 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3167721F8530; Thu, 15 Nov 2012 12:11:40 -0800 (PST)
Received: by bofh.nohats.ca (Postfix, from userid 500) id E363A82B75; Thu, 15 Nov 2012 15:10:51 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A6BC182B5B; Thu, 15 Nov 2012 15:10:51 -0500 (EST)
Date: Thu, 15 Nov 2012 15:10:51 -0500
From: Paul Wouters <paul@nohats.ca>
To: Ben Laurie <benl@google.com>
In-Reply-To: <CABrd9SSv7vfxOhogGmYSWC8hROyXL_z4TJC8mxNMW-apSg5Y0Q@mail.gmail.com>
Message-ID: <alpine.LFD.2.02.1211151501490.17666@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>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
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: Thu, 15 Nov 2012 20:11:41 -0000

On Wed, 14 Nov 2012, Ben Laurie wrote:

>> I think CT is a bandaid for PKIX that does not apply to DANE.
>>
>> I think the problem with DANE/DNSSEC right now is the additional latency
>> and dns transport issues (hotspots, VPN, etc) but I don't think CT is
>> very well suited to address those.
>
> a) Why would an attacker use your validity times?

Because there are DNSSEC keys to back the time slots used, and
without it, the data can and should be rejected.

> b) Weren't you amongst those asking for CT to support DANE during the BoF?

I wanted CT to not exclude DANE, and thereby enforcing an artificial TLS
certificate market where I have to pay $10-$150 a year to be "accepted"
in browsers via CT. What I understood was that browser vendors that
were looking at CT and DANE would specifically not be supoprted. The
first thought was to have a DANE backed CT that could be configured,
purely to get the DANE information (valid key + TTL/RRSIG info) into
the browsers that don't support or want to support DNSSEC (chains).

But the DANE/DNSSEC information does not need an publicly shared audit
log. Its current up to date  validity is available in the DNS at all
times, cached and distributed.

Paul