Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer

fujiwara@jprs.co.jp Thu, 05 November 2020 04:40 UTC

Return-Path: <fujiwara@jprs.co.jp>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6FF3A138E for <dnsop@ietfa.amsl.com>; Wed, 4 Nov 2020 20:40:11 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 hxdSx8J7G56Z for <dnsop@ietfa.amsl.com>; Wed, 4 Nov 2020 20:40:09 -0800 (PST)
Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (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 419453A0FFB for <dnsop@ietf.org>; Wed, 4 Nov 2020 20:40:08 -0800 (PST)
Received: from off-sendsmg31.osa.jprs.co.jp (off-sendsmg31.osa.jprs.co.jp [172.23.8.161]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id 0A54e6A0013827; Thu, 5 Nov 2020 13:40:06 +0900
Received: from off-sendsmg31.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss91 (Postfix) with ESMTP id 7171A6024086; Thu, 5 Nov 2020 13:40:05 +0900 (JST)
Received: from localhost (off-cpu08.osa.jprs.co.jp [172.23.4.18]) by off-sendsmg31.osa.jprs.co.jp (Postfix) with ESMTP id 661366024082; Thu, 5 Nov 2020 13:40:05 +0900 (JST)
Date: Thu, 05 Nov 2020 13:40:05 +0900 (JST)
Message-Id: <20201105.134005.1780523490629617625.fujiwara@jprs.co.jp>
To: rharolde@umich.edu
Cc: dnsop@ietf.org
From: fujiwara@jprs.co.jp
In-Reply-To: <CA+nkc8D_6vrdH7dkgqfdDKq+prGjDAsUUd+bcFgj+sH7oJhHRg@mail.gmail.com>
References: <20201104.133137.359450294432060529.fujiwara@jprs.co.jp> <CA+nkc8D_6vrdH7dkgqfdDKq+prGjDAsUUd+bcFgj+sH7oJhHRg@mail.gmail.com>
X-Mailer: Mew version 6.8 on Emacs 24.5
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSS-9.1.0.1231-8.6.0.1013-25768.005
X-TM-AS-Result: No--14.931-5.0-31-10
X-imss-scan-details: No--14.931-5.0-31-10
X-TMASE-Version: IMSS-9.1.0.1231-8.6.1013-25768.005
X-TMASE-Result: 10--14.930800-10.000000
X-TMASE-MatchedRID: HbMQjQPEfdJCXIGdsOwlUu5i6weAmSDKYawhvkuLgj6qvcIF1TcLYH4b +EgKGbJqFb6jOEcIcVozcFuohvIF7AHYCNT1xjfzamejoqUad3rkbMASTwgriLrRhKi00AQB1ZG U7XvKVpkRkfWwyxiYwnwLyTE8Sb+8jUPFUUIcEyc9k+RrKgLy2DA5mGjf3tJWkaEC8FJraL9I6i ia8EJZLg/KrwW58+ofvNnJir6R0nDK7meRl+9tzaHggtOWAEvR+D+zbdY8Eim9eNsTtvBD3nGCP Ah3PmLX8JDf06DACvOruIOl4LurGLfBrkBZSdWArKAvSPiudyH4qCLIu0mtIDyC5ddG2JcgPCC7 nOxCdYrbpsq+MnNpYwYh55c2TdgGmrcavHa2c/74AIbmhYnu0oeete0CDyUjGIQxNXSr4+q48mO EobffOMEdp0H/3boryadLT5Muhv2Pl8suWHSuVJ4CIKY/Hg3AtOt1ofVlaoKm8jxRk5/juH1qym 0z6Q4r8BdxbGBwPnKxmoQAAdv2lPoLR4+zsDTt9Ss5ONHRGPWyng46gD8a7NFVIw8PKHpuOyDhv uW23dXWmVRcxrPmuA==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tDkA-uDqQ0h6g2czA0uHfL-jfdk>
Subject: Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2020 04:40:11 -0000

> From: Bob Harold <rharolde@umich.edu>
> If an attacker is spoofing responses, it seems that they could send a
> different NS and A record, and a new calculated DS hash.  So this provides
> no protection against spoofing?
> 
> We would need instead (or in addition) an RRSIG record to actually protect
> this.

Thanks for reading the draft.

I'm assuming that DiS RR is treated as the DS RR, so if the parent
side is signed, DS (+DiS) RRSet will be signed.

> An example would help.

Yes. I will add examples in next version.

example.com.    IN NS ns.example.com.
ns.example.com. IN A 2001:dc8::53
example.com.    IN DS 12345 8 2 (hash of DNSKEY RR)
example.com.    IN DS 00000 0 100 (hash of (example.com IN NS | ns.example.com IN AAAA))
example.com.    IN RRSIG DS (signature of DS RRSet (2 DSes))

DNSSEC signer may generate DiS RR and signature of DS RRSet (including DiS RR).

--
Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>

> -- 
> Bob Harold
> DNS and DHCP Hostmaster - UMNet
> Information and Technology Services (ITS)
> rharolde@umich.edu   734-512-7038
> 
> 
> On Tue, Nov 3, 2020 at 11:31 PM <fujiwara@jprs.co.jp> wrote:
> 
>> I submitted draft-fujiwara-dnsop-delegation-information-signer-00.
>>
>> Name:           draft-fujiwara-dnsop-delegation-information-signer
>> Revision:       00
>> Title:          Delegation Information (Referrals) Signer for DNSSEC
>> Document date:  2020-11-03
>> Group:          Individual Submission
>> Pages:          6
>> URL:
>> https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt
>>
>> DNSSEC does not have a function to validate delegation information.
>> I think it is a large missing peace of DNSSEC.
>>
>> I have a question why we did not include signature validation function
>> to delegation information ?
>>
>> Probably, because it is non-authoritative information.
>> Or, because it was difficult to define the necessary and sufficient
>> delegation information.
>>
>> It is now widely agreed (although not explicitly documented) that the
>> delegation information is the information used for name resolution and
>> does not result in name resolution.
>>
>> We have a word "in-domain" glue which is the necessary and sufficient glue.
>>
>> And the idea may offer the signature for root priming data.
>>
>> If someone interested the document, I would like time slot at dnsop WG
>> meeting.
>>
>> Regards,
>>
>> --
>> Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>