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