Re: [therightkey] [dane] DANE and CT
Paul Wouters <paul@nohats.ca> Thu, 15 November 2012 20:33 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 9F64421F892D; Thu, 15 Nov 2012 12:33:34 -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=[AWL=0.000, 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 VCOHsaZzcdYe; Thu, 15 Nov 2012 12:33:34 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id DD5CA21F892B; Thu, 15 Nov 2012 12:33:33 -0800 (PST)
Received: by bofh.nohats.ca (Postfix, from userid 500) id 85A3782B75; Thu, 15 Nov 2012 15:32:47 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6F22982B5B; Thu, 15 Nov 2012 15:32:47 -0500 (EST)
Date: Thu, 15 Nov 2012 15:32:47 -0500
From: Paul Wouters <paul@nohats.ca>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CF602349-8B21-4429-B518-AFD17D6E72FC@vpnc.org>
Message-ID: <alpine.LFD.2.02.1211151516120.17666@bofh.nohats.ca>
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> <20121114181437.GA26508@isc.upenn.edu> <CF602349-8B21-4429-B518-AFD17D6E72FC@vpnc.org>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: therightkey@ietf.org, Shumon Huque <shuque@upenn.edu>, 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 20:33:34 -0000
On Thu, 15 Nov 2012, Paul Hoffman wrote: > On Nov 14, 2012, at 10:14 AM, Shumon Huque <shuque@upenn.edu> wrote: > >> 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 ... > > This is an excellent summary of the scenario. > > However, that's not exactly what Ben is asking about. CT-for-PKIX is about "did a trusted CA issue a certificate it should not have". CT-for-DNSSEC is about "did a server in the hierarchy above the leaf include a DS it should not have". In the latter case, those rogue DS records might not be detectable to the party with the leaf record. > > For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of requests (such as to a particular geographic region or set of network addresses), the party with the private key associated with B can spoof example, and the owner of example would not know unless he could see B. Interesting. I had not considered this because a big difference is that such rogue DNS records would not be contained/targetted. The forged DS created by the parent would quickly expose the parent, and I doubt the parents would want that reputation damage. Unless they are totalitarian governments, but unlike phb, I give up any kind of using the internet against advisaries that are physically in the path - it just ends up with you refusing to be lied to and not connecting, or going along with their lies and getting eavesdropped. But I'm not sure how CT would see the difference between me logging in to my registrar interface and updating the DS record, someone else using my credentials to do the same without my knowledge, or the registry going rogue. The way PKIX-CT does this is via some financial transaction pretending to convey trust and authority and a credit card audit trail. It fails for the common user precisely because it costs money, and today's criminals have more money to invest compared to the average internet user. I also don't see how TACK addresses this either, with their complicated pinning schemes that are just many different ways of shooting yourself in the foot, without adding anything to the DANE pinning method (apart from relying on verisign to not forfeit their root zone contract to sign custom data for anyone) So I think CT could be used as DNSSEC/DANE history audit log, but IMHO the main asset of something like CT based DANE is purely as a better transport layer for DNSSEC - not as a replacement for DANE/DNSSEC. DNSSEC points to the publisher, who is defined as always right (even if they are wrong because they are sloppy or have a gun pointed at their heads) 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