Re: [dane] CT for DNSSEC

"Paul Hoffman" <paul.hoffman@vpnc.org> Fri, 17 March 2017 18:20 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 112D312706D; Fri, 17 Mar 2017 11:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 DM9WpxKhWnHW; Fri, 17 Mar 2017 11:20:10 -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 5E979124D68; Fri, 17 Mar 2017 11:20:10 -0700 (PDT)
Received: from [10.32.60.17] (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 v2HIK0uI006297 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 11:20:01 -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.17]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Wei Chuang <weihaw@google.com>
Cc: trans@ietf.org, dane@ietf.org
Date: Fri, 17 Mar 2017 11:20:06 -0700
Message-ID: <C54BF614-378D-4A0A-964F-AE372E064D42@vpnc.org>
In-Reply-To: <CAAFsWK2z1AR6RZToQvw7s_t_u+333Jyk6pUQ5KznbsrQGxkvgQ@mail.gmail.com>
References: <CAAFsWK0bCDZmg0csCfXAJ1=jqbOBc7sUUvSg-6ZKjxuAQKmQPA@mail.gmail.com> <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <CAAFsWK2z1AR6RZToQvw7s_t_u+333Jyk6pUQ5KznbsrQGxkvgQ@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/PfPPljzVS9L_qHNsyuS-5G740_w>
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: Fri, 17 Mar 2017 18:20:12 -0000

On 17 Mar 2017, at 9:31, Wei Chuang wrote:

> On Thu, Mar 16, 2017 at 10:25 AM, Paul Hoffman <paul.hoffman@vpnc.org>
> wrote:
>
>> 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.
>>
>
> Is this because you're worried about the parent removing evidence of 
> DNSSEC
> for the child in the spoofing scenario?

No, this is because the parent can spoof any data for the child. It is 
unrelated to DNSSEC.

> If the parent tries to spoof with
> DNSSEC for the child I would assume that seeing the DS SCT's in the 
> log,
> that is sufficient to find evidence of spoofing.  That said I think it
> could be helpful to log NS as well for forensics.

Transcripts are useful even when the logged data is not cryptographic.

> One issue with logging all records seen is if webmail providers 
> publish
> SMIMEA there will be a potentially overwhelming number of records 
> logged,
> and a very large change rate.

Don't log what you can't log due to scale.

> Another issue is privacy of such records.

Sure, but there are unpredictable privacy issues with lots of DNS record 
data. It's not possible for us to predict what will and will not be 
considered private information now or in the future for anyone other 
than ourselves.

>> In both cases, having transcripts from various DNS looking glasses 
>> around
>> the Internet would give greater assurance of the integrity of the
>> transcript.
>
>
> I agree that would a good idea.

--Paul Hoffman