Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

Mukund Sivaraman <muks@mukund.org> Tue, 19 June 2018 23:15 UTC

Return-Path: <muks@mukund.org>
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 B0041130FE9 for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 16:15:24 -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, 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 XBq9eV4UJBgC for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 16:15:22 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBD4130E4D for <dnsop@ietf.org>; Tue, 19 Jun 2018 16:15:22 -0700 (PDT)
Received: from jurassic (unknown [14.194.232.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id AA72832C0A39; Tue, 19 Jun 2018 23:15:18 +0000 (UTC)
Date: Wed, 20 Jun 2018 04:45:12 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Shumon Huque <shuque@gmail.com>
Cc: petr.spacek@nic.cz, "dnsop@ietf.org WG" <dnsop@ietf.org>
Message-ID: <20180619231512.GA26273@jurassic>
References: <4DCC5A51-1AB0-47B6-92B5-79B6894F9A9C@verisign.com> <CAJE_bqcELQbQeHPvvEBHOxpRyWYL76BmT_-G4jW4pTnUUXFMUw@mail.gmail.com> <27C44216-581A-4991-A739-ECE8B7F8AA35@verisign.com> <884c2d11-9db0-7668-59c9-baa8574a03f7@time-travellers.org> <37873808-8354-b26b-34f4-880ea7a5f0da@nic.cz> <CAHPuVdWXBDHdiQ2Z1uFx=mZFRBpjndiki+6Eno-2qFoe6hAovw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHPuVdWXBDHdiQ2Z1uFx=mZFRBpjndiki+6Eno-2qFoe6hAovw@mail.gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DUb7vOTrRzXVFGtUkLKhrTqfcfU>
Subject: Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 19 Jun 2018 23:15:25 -0000

On Tue, Jun 19, 2018 at 02:11:02PM -0400, Shumon Huque wrote:
> On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček <petr.spacek@nic.cz> wrote:
> 
> >
> > I think we need to first answer question why existing technologies do
> > not fit the purpose.
> >
> 
> This is a reasonable question.
> 
> I noticed that the draft doesn't mention SIG(0) at all. One of the main
> motivators of the draft is stated to be secure, wide scale distribution of
> the root zone. To me, SIG(0) would have been an obvious candidate solution
> for this problem. The zone owner can publish one public key to the world,
> and signs zone transfers messages with the corresponding secret key. If the
> zone owner supports IXFR, the incremental cost of these message signatures
> is also quite small.

There also seems to be a scalability problem with SIG(0) in that
generating the signature involves a public-key operation per DNS
message.

For a zone transfer of the root zone from F, the AXFR contains 79
messages in the TCP continuation:

;; XFR size: 22554 records (messages 79, bytes 1335768)

Unfortunately, because the request message's fields are involved in
calculating the signature for the reply message and the ID also varies,
it doesn't appear that the signatures can be re-used.

This scalability problem is probably a reason why TSIG's HMAC has become
the preferred method for transaction security and SIG(0) isn't used to
authenticate zone transfers.

		Mukund