IETF Logo Mail Archive

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

Ondřej Caletka <Ondrej.Caletka@cesnet.cz> Sat, 24 June 2017 15:45 UTC

Return-Path: <Ondrej.Caletka@cesnet.cz>
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 8234B126C3D for <dnsop@ietfa.amsl.com>; Sat, 24 Jun 2017 08:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
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 sIYlAxwypzLH for <dnsop@ietfa.amsl.com>; Sat, 24 Jun 2017 08:45:52 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C4C12441E for <dnsop@ietf.org>; Sat, 24 Jun 2017 08:45:50 -0700 (PDT)
Received: from [IPv6:2a03:3b40:210::1a1e] (latte.t512.oskarcz.net [IPv6:2a03:3b40:210::1a1e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id EADD520066; Sat, 24 Jun 2017 17:45:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1498319149; bh=eiZl2CX2ehi4+Nl8wOxtesjEGOtn/7nyQjdG96Pc58E=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=a7+iUR5yO5E5LXCo48ewVN/Evn5r4pEZBtdL8n5d7moM3GYHc69sa3xx6obEQb9bz 5Tgzv28+1llbneV4dnTvIMNZuZwnlLp70hF29aMSKIbZC2utLxOT+gs4f+/WCH4JGY sehQwQLubszkNEO3XiB7T0j8TL0V+PkqGcGcOiXM=
To: Dick Franks <rwfranks@acm.org>, Ólafur Guðmundsson <olafur@cloudflare.com>
References: <20170623105434.22478B810AB@rfc-editor.org> <CAN6NTqyBg74NF-F8imGiK0ArwxAbhc0uE_xXbX-No+Le8E9DUg@mail.gmail.com> <CAKW6Ri7npS57gupPrUc2aGhsg21u8csx+69GKrCFkeQ6H5Dnxw@mail.gmail.com>
Cc: RFC Editor <rfc-editor@rfc-editor.org>, tjw.ietf@gmail.com, IETF DNSOP WG <dnsop@ietf.org>, suzworldwide@gmail.com, pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson <olafur+ietf@cloudflare.com>
From: Ondřej Caletka <Ondrej.Caletka@cesnet.cz>
Message-ID: <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz>
Date: Sat, 24 Jun 2017 17:45:47 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAKW6Ri7npS57gupPrUc2aGhsg21u8csx+69GKrCFkeQ6H5Dnxw@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020301030305010100060603"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QiSuDsoYBfELWb8upexJKVPr0gc>
Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 24 Jun 2017 15:45:54 -0000

Hello,

Dne 24.6.2017 v 15:25 Dick Franks napsal(a):
> I beg to disagree.
> 
> In each case,
> 
>       CDS 0 0 0 0
> 
>       CDNSKEY 0 3 0 0
> 
> the final "0" is a conventional token representing a zero-length key
> field. In neither case is it an attempt to specify a single octet key value.

I believe this has been discussed between 04 and 06 versions of the
draft in this thread:

https://mailarchive.ietf.org/arch/msg/dnsop/PsRIQOtd1bxFSEEm9lfv0WaHKeE

The result that made it to the RFC is that there should be indeed one
byte with value of 00 in the Digest/Public key field instead of no data
at all. This avoids the need of defining new format and updating all the
deployed software. It's not only about parsers of the wire format but
also about zone file parsers, that would need an update as the single
zero is not conformant with currently defined presentation format of
CDS/CDNSKEY RRs.

I believe changing RRdata format just for this one purpose would add an
unnecessary complexity.

--
Best regards,
Ondřej Caletka

v2.23.0 | Report a Bug | By Email