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
- [therightkey] DANE and CT Ben Laurie
- Re: [therightkey] [dane] DANE and CT Ben Laurie
- Re: [therightkey] [dane] DANE and CT Tony Finch
- Re: [therightkey] [dane] DANE and CT Warren Kumari
- Re: [therightkey] [dane] DANE and CT Paul Wouters
- Re: [therightkey] [dane] DANE and CT Ben Laurie
- Re: [therightkey] [dane] DANE and CT Tom Ritter
- Re: [therightkey] [dane] DANE and CT Tony Finch
- Re: [therightkey] [dane] DANE and CT Ben Laurie
- Re: [therightkey] [dane] DANE and CT Shumon Huque
- Re: [therightkey] [dane] DANE and CT Tom Ritter
- Re: [therightkey] [dane] DANE and CT Ben Laurie
- Re: [therightkey] [dane] DANE and CT Carl Wallace
- Re: [therightkey] [dane] DANE and CT Shumon Huque
- Re: [therightkey] [dane] DANE and CT Frederico A C Neves
- Re: [therightkey] [dane] DANE and CT Phillip Hallam-Baker
- Re: [therightkey] [dane] DANE and CT Paul Hoffman
- Re: [therightkey] [dane] DANE and CT Shumon Huque
- Re: [therightkey] [dane] DANE and CT Paul Wouters
- Re: [therightkey] [dane] DANE and CT Paul Wouters
- Re: [therightkey] [dane] DANE and CT Danny McPherson
- Re: [therightkey] [dane] DANE and CT Phillip Hallam-Baker
- Re: [therightkey] [dane] DANE and CT Danny McPherson
- Re: [therightkey] [dane] DANE and CT Ben Laurie
- Re: [therightkey] [dane] DANE and CT Ben Laurie
- Re: [therightkey] [dane] DANE and CT Paul Wouters
- Re: [therightkey] [dane] DANE and CT Paul Wouters
- Re: [therightkey] [dane] DANE and CT Paul Hoffman
- Re: [therightkey] [dane] DANE and CT Phillip Hallam-Baker
- Re: [therightkey] [dane] DANE and CT James Cloos
- Re: [therightkey] [dane] DANE and CT Ben Laurie