Re: [dane] CT for DNSSEC

"Paul Hoffman" <paul.hoffman@vpnc.org> Thu, 16 March 2017 17:25 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218121296C4; Thu, 16 Mar 2017 10:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 l7dJX4f7OcmW; Thu, 16 Mar 2017 10:25:12 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865FF127843; Thu, 16 Mar 2017 10:25:12 -0700 (PDT)
Received: from [10.32.60.31] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v2GHP2ro022144 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Mar 2017 10:25:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.31]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Wei Chuang <weihaw@google.com>
Cc: trans@ietf.org, dane@ietf.org
Date: Thu, 16 Mar 2017 10:25:08 -0700
Message-ID: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org>
In-Reply-To: <CAAFsWK0bCDZmg0csCfXAJ1=jqbOBc7sUUvSg-6ZKjxuAQKmQPA@mail.gmail.com>
References: <CAAFsWK0bCDZmg0csCfXAJ1=jqbOBc7sUUvSg-6ZKjxuAQKmQPA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/vBdX3Raqvmxtkh2u9i87AsO2rPs>
Subject: Re: [dane] CT for DNSSEC
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Mar 2017 17:25:14 -0000

On 16 Mar 2017, at 10:09, Wei Chuang wrote:

> I saw there was significant interest
> <http://blog.huque.com/2014/07/dnssec-key-transparency.html> in 
> exploring
> CT for DNSSEC back in 2014 of which a draft 
> draft-zhang-trans-ct-dnssec
> <https://tools.ietf.org/html/draft-zhang-trans-ct-dnssec-03> was 
> created.
> It seems to have quieted down since.  I believe the motivation is 
> still
> there which is to prevent a parent zone from potentially misbehaving 
> and
> spoofing the child zone.  Is there still interest in this?  From the 
> list
> archives, I can't see what the issues were though I'm guessing one of 
> them
> was respecifying the DS resource record to use a SCT which might have
> caused compatibility concerns.  (But please correct me if I'm wrong)  
> Other
> than that, the draft seems pretty reasonable.  Were there other 
> concerns?

There were two separate issues that got conflated at the time:

- Seeing evidence that a parent had spoofed DNSSEC keys for a child. A 
transcript of the DS records in the parent is sufficient as long as the 
child doesn't have relying parties create islands of trust (which is 
relatively rare these days).

- Seeing evidence that a parent had spoofed any resource records for a 
child. A transcript of the NS records in the parents is a good start, 
although what is really needed is a transcript of everything that is 
seen for the child.

In both cases, having transcripts from various DNS looking glasses 
around the Internet would give greater assurance of the integrity of the 
transcript.

--Paul Hoffman