Re: [Trans] DNSSEC also needs CT

Paul Wouters <paul@nohats.ca> Tue, 13 May 2014 13:55 UTC

Return-Path: <paul@nohats.ca>
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 372BD1A00F0 for <trans@ietfa.amsl.com>; Tue, 13 May 2014 06:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 0qMDVbjpo71R for <trans@ietfa.amsl.com>; Tue, 13 May 2014 06:55:12 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id CCA6E1A0096 for <trans@ietf.org>; Tue, 13 May 2014 06:55:12 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E24FE81703; Tue, 13 May 2014 09:55:05 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1399989305; bh=dKCzEX8lWN4vAgZ1nFDsTgQspVGqXQ1wd+8MI7EwW1k=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JRDmUyy1NwZVVltBmPmr/C9KETZepFg8kc31XtFd5QpwHR2MV7cwWPHUqpM1vJ/l9 M+s+u+0bUJ1P3Dp90oc6vyccWcnxkB1Zf/vrcGMCgDQ/wurQu/CxyX0oV8RdOwKj55 LVnvw8mSyaAzp82fnlm4lz9Ogkged2z6dL4qqOek=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4DDt5xj027859; Tue, 13 May 2014 09:55:05 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 13 May 2014 09:55:05 -0400
From: Paul Wouters <paul@nohats.ca>
To: Ben Laurie <benl@google.com>
In-Reply-To: <CABrd9STYxmK6gg7a5wDtejdc_Y0aD9hwQkHpFu3HbxVbMZDQHQ@mail.gmail.com>
Message-ID: <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>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Vb5Yjv0JDPfFzRU8U4jmHuTNSGU
Cc: "trans@ietf.org" <trans@ietf.org>
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 13:55:18 -0000

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.

Paul