Re: [Trans] DNSSEC also needs CT

Joseph Bonneau <jbonneau@gmail.com> Mon, 12 May 2014 17:23 UTC

Return-Path: <jbonneau@gmail.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 675821A0760 for <trans@ietfa.amsl.com>; Mon, 12 May 2014 10:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 hgo9Y4VWjkyo for <trans@ietfa.amsl.com>; Mon, 12 May 2014 10:23:08 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2561A075D for <trans@ietf.org>; Mon, 12 May 2014 10:23:08 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id lg15so9106401vcb.7 for <trans@ietf.org>; Mon, 12 May 2014 10:23:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lbsKXvJH9jKKAdVr9bTTKc4QqbnYqTjq8inBwX80hXM=; b=FABHn6/TMkL2gh6LLrHiJM5m3mSpEH/8bkLEcZq+3GhF6ONruDwBqBkfcJC5h3lO4u abXA6DpGGuPBbxdXH5zeLZwAN8qv/Dovxl2dgbL4S++bEebpX1INMVjVCJPmYpW4wk50 cxoQ1fkze/uX0LYJTK2HWpACJHuTRvXJUTrAkYO+x1omCA+HjG73MNqALtFZesoFGOHP OUUjuraElCAGgYugiQXUafyTuYJwwqEeNaQbvVGToYA/LSYE9LbLB3VNcTJNp8i6q0vC RhZSeGpYVocfMt3X3TUXn1M9IUrr5XzrzygVpLJfyCG9Uus9aH8yt7PCPBWNRoOgaE2z /fQw==
X-Received: by 10.220.59.65 with SMTP id k1mr24115731vch.22.1399915381954; Mon, 12 May 2014 10:23:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.86.136 with HTTP; Mon, 12 May 2014 10:22:41 -0700 (PDT)
In-Reply-To: <CABrd9ST7K-7RGwGD2G+kDcVSceC2ZJ-5Tz2tdp5NWa3cqBK+-w@mail.gmail.com>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <CAMm+Lwieij8Tm8V-gpE0eAfwie1dgtFL_Ga8dPkJFKJKLQDAcA@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>
From: Joseph Bonneau <jbonneau@gmail.com>
Date: Mon, 12 May 2014 13:22:41 -0400
Message-ID: <CAOe4Ui=nqmCfjBYNE2CJtEs1jnbavpY4Dv-T3FRDdAwAA2dScg@mail.gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary=001a11c295020e9d7704f937332f
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/eBGRYl_Vb4aIHVhr68w4vQaXwxw
Cc: Warren Kumari <warren@kumari.net>, Paul Wouters <paul@nohats.ca>, "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: Mon, 12 May 2014 17:23:10 -0000

>
> Or just say that anyone who puts in more than X amount of DNSSEC CT
>> entries underneath themselves must run a public CT node themselves. So
>> if nohats.ca want to get more then X entries, or one of their
>> subzones/customers wants more than X entries, either they or their
>> subzone/customer will have to run a fully functional CT node. And if
>> the node goes down, their new entries will be refused.
>
>
> Yes, exactly. +1
>

I'm wondering what the exact threat model is here. Imagine a malicious
domain operator wants to sign some DNSSEC records for use in an attack.
They include hashed of them in their log, then claim to "lose" the original
records, or issue the equivalent of SCTs and then never include them within
the MMD. Who is checking up on them for this? Does the superdomain that
signs this domain's record has to be doing full auditing of their DNSSEC-CT
log? Does this still work then as anti-DOS if the superdomain has to do all
of this auditing anyways (I suppose it could be made random, but then the
domain can try to hide malicious entries with lots and lots of spam ones).

Furthermore, is this requirement recursive? What if a malicious domain
evil.com agrees with a subdomain really.evil.com to not audit their
DNSSEC-CT log properly, so malicious records can be signed for
really.evil.com, not audited by evil.com, but if com (who we assume is
honest) only audits evil.com's log they'll think it's in valid order. Is
there a way to prevent the root from having to audit every log everywhere?

Also, the penalty for failing some audit check is losing control of your
domain? That seems like a sufficient disincentive that few domains will
want to go beyond whatever their superdomain's policy is and have to run
their own log, enough that some current practices (like giving users of a
website their own subdomain) would be affected.