Re: [Trans] DNSSEC also needs CT

Nico Williams <nico@cryptonector.com> Tue, 13 May 2014 14:41 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B5F1A00BC for <trans@ietfa.amsl.com>; Tue, 13 May 2014 07:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfG-bX9066EG for <trans@ietfa.amsl.com>; Tue, 13 May 2014 07:41:31 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EA0CC1A00B2 for <trans@ietf.org>; Tue, 13 May 2014 07:41:30 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id C15361B406B for <trans@ietf.org>; Tue, 13 May 2014 07:41:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=acalljOfzrWXE4FD7xrc WWbQwI8=; b=giWlr9VSW7jMmMTEMOblM8QPQHw0GdILmGt/ZcaXp+9pCHOJbew4 q0rekwlPAI1GeF1C70fYouC++sE51FNhyVkjxeVrQL5r/GRUbUyNLJzt/zIZG6b+ ze2fRH8sUjTrYyBFbf1WjltxzSNALuIelDdi9mDodYws1zVKDrTcMPw=
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 6641B1B4061 for <trans@ietf.org>; Tue, 13 May 2014 07:41:24 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hi2so6370859wib.17 for <trans@ietf.org>; Tue, 13 May 2014 07:41:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.108.147 with SMTP id hk19mr21112232wib.42.1399992082989; Tue, 13 May 2014 07:41:22 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Tue, 13 May 2014 07:41:22 -0700 (PDT)
In-Reply-To: <alpine.LFD.2.10.1405130948160.25023@bofh.nohats.ca>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <CAK3OfOiKjY6YyiyeHiFJrecZfj_uQ-2k+KucKnzb9Yt8VCRPOQ@mail.gmail.com> <CAHw9_iKpN7AXfrH6SzroMukrKTPR5z24U9KfWpVW-F2R_wX3ag@mail.gmail.com> <alpine.LFD.2.10.1405101722240.897@bofh.nohats.ca> <CABrd9ST7K-7RGwGD2G+kDcVSceC2ZJ-5Tz2tdp5NWa3cqBK+-w@mail.gmail.com> <CAOe4Ui=nqmCfjBYNE2CJtEs1jnbavpY4Dv-T3FRDdAwAA2dScg@mail.gmail.com> <CAK3OfOiYMJkXVR+QsCzEV0ir6u53coJz0b-JdGGD5bTTz5YcMg@mail.gmail.com> <CAOe4Ui=u0fkm9_nuXx_6gpH6jHM5pBvzjzru9O8y3bpLkA0qmw@mail.gmail.com> <CAK3OfOi6y=QAMXe_2axiavxwR5nS2Uv8SM4JxQHsvEKbUyNGCA@mail.gmail.com> <CAOe4Uimvc6e6u=fJjM1-iaOTepA33Sx5CBjMV9dB8sSLqtZoWA@mail.gmail.com> <CAK3OfOhdhWdGvvhuaGyE_p5kLy0ZX-V5sAXfoLGP_8d8vPJDgg@mail.gmail.com> <CAOe4Uik+fjM4wTVBiFxphVZAwVYBPgd1a9xUyUBMSFy30SWNLg@mail.gmail.com> <CAK3OfOiC+5+s2UtSEP788W23tHq6VQSQfMsUboUp16L-27zsvQ@mail.gmail.com> <CABrd9STYxmK6gg7a5wDtejdc_Y0aD9hwQkHpFu3HbxVbMZDQHQ@mail.gmail.com> <alpine.LFD.2.10.1405130948160.25023@bofh.nohats.ca>
Date: Tue, 13 May 2014 09:41:22 -0500
Message-ID: <CAK3OfOjj-O-Oy6u_83hAAfjgdmBiCg6zmLo_T8j3Z0J0ymTJjQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/bxs-weiUYLlxXcmmzTm8XHstPNg
Cc: "trans@ietf.org" <trans@ietf.org>, Ben Laurie <benl@google.com>
Subject: Re: [Trans] DNSSEC also needs CT
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 14:41:32 -0000

On Tue, May 13, 2014 at 8:55 AM, Paul Wouters <paul@nohats.ca> wrote:
> On Tue, 13 May 2014, Ben Laurie wrote:
>
> [DNSSEC CT]
>
>
>> Is it necessary to log anything other than keys? My base assumption was
>> no: if the keys are as expected, then all records signed by those keys
>> can be trusted. If someone wants to publish RRsets that are other than the
>> one the true domain owner wants to publish, they necessarily have
>> to inject a key they control, which becomes apparent from the logs.
>
>
> That would not allow us to detect coercion, that is a custom RRset signed
> to be used only for a targetted attack (by say, .com or the root)
>
> But I'm not sure how we _could_ detect that. Let's say they get an A
> record for www.victim.com that bypasses the NS RRset completely, that
> is, signed by the .com key. To notice this case, you would also need to log
> the change of zone cut.
>
> The other case is injection of a custom DS RRset. How would we tell the
> difference between the legitimate zone owner adding a DS record or an
> attacker/parent zone owner adding one? One defense would be to ignore
> any new DS record for a certain amount of time, but that runs into
> similar issues as pinning and TACK.

Yes, these are the issues that need resolving.  Hashing the RRset name
doesn't help either where the attack is based on inserting a different
RRset to misdirect the victim.  Nor is it possible to audit logs to
look for such attacks if there's no names.

Still, if the goal is to get the root(s) and TLDs to stay honest, and
since they don't need privacy, their logs can include unhashed names.
Further below in the hierarchy things get murky; I have no answers as
to those, but it seems likely that some (most! probably) zones below
the TLDs will absolutely want protection against zone enumeration.  Is
a modicum of privacy possible with CT for the PKI?

Nico
--