Re: [therightkey] [dane] DANE and CT
Shumon Huque <shuque@upenn.edu> Wed, 14 November 2012 18:14 UTC
Return-Path: <shuque@upenn.edu>
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 5179F21F8758; Wed, 14 Nov 2012 10:14:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 MJazXCjdpGG0; Wed, 14 Nov 2012 10:14:38 -0800 (PST)
Received: from mopeypopo.net.isc.upenn.edu (www.huque.com [IPv6:2607:f470:2:1::a:2]) by ietfa.amsl.com (Postfix) with ESMTP id B3A7721F86A8; Wed, 14 Nov 2012 10:14:38 -0800 (PST)
Received: by mopeypopo.net.isc.upenn.edu (Postfix, from userid 500) id E70B3A5002; Wed, 14 Nov 2012 13:14:37 -0500 (EST)
Date: Wed, 14 Nov 2012 13:14:37 -0500
From: Shumon Huque <shuque@upenn.edu>
To: Ben Laurie <benl@google.com>
Message-ID: <20121114181437.GA26508@isc.upenn.edu>
References: <CABrd9SRyv+UerPJBf+gw47nWj3t4ekHRnWsKC0pHcadHV5mvmw@mail.gmail.com> <alpine.LSU.2.00.1211141601220.27013@hermes-1.csi.cam.ac.uk> <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <alpine.LSU.2.00.1211141640120.15409@hermes-1.csi.cam.ac.uk> <CABrd9ST8duM=U-0g02yres_qEY5tnLY6dXLJzxcXiKYEqmiFNA@mail.gmail.com> <20121114172950.GA13499@isc.upenn.edu> <CABrd9SSMq8RQVTB7OWHEULC0Kwy-XqXEiKzEE5e6O7cG1_6Hiw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABrd9SSMq8RQVTB7OWHEULC0Kwy-XqXEiKzEE5e6O7cG1_6Hiw@mail.gmail.com>
Organization: University of Pennsylvania
User-Agent: Mutt/1.5.21 (2010-09-15)
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: Wed, 14 Nov 2012 18:14:39 -0000
On Wed, Nov 14, 2012 at 05:56:24PM +0000, Ben Laurie wrote: > On 14 November 2012 17:29, Shumon Huque <shuque@upenn.edu> wrote: > > On Wed, Nov 14, 2012 at 05:07:58PM +0000, Ben Laurie wrote: > >> On 14 November 2012 17:02, Tony Finch <dot@dotat.at> wrote: > >> > Warren Kumari <warren@kumari.net> wrote: > >> >> > >> >> If I run example.com and someone managed to generate / publish a TLSA > >> >> record for that I'd sure like to know about it. > >> > > >> > Right. But in PKIX a mis-issued certificate has nothing to do with your > >> > own infrastructure, whereas with DANE it implies that your infrastructure > >> > (or the infrastructure of your DNS service providers) has been > >> > compromised. > >> > >> Isn't the infrastructure of your DNS service providers nothing to do > >> with your own infrastructure? Not to mention your TLD's > >> infrastructure, and that of all of their registrars (and, presumably, > >> DNS service providers)? > > > > One critical difference is that with DANE, I can query the DNSSEC > > delegation chain myself and detect whether my TLD has installed a > > bogus DS record and take action. I cannot today detect a bogus > > X.509 cert by myself. I think this makes a CT like scheme less necessary > > for DANE. > > You can't detect a bogus X.509 cert because you can't connect to the > server serving it, presumably. What magic allows you to perform this > trick for DNS but not HTTPS? For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC authentication chain, not the existence of a fraudulently issued certificate on some attacker's server. If the DNSSEC chain is intact, then presumably DANE aware clients will properly authenticate the TLSA record before accepting the server certificate. I admit that's a mighty presumption today, but we'll see ... -- Shumon Huque University of Pennsylvania.
- [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