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

Matthijs Mekking <matthijs@pletterpet.nl> Mon, 26 June 2017 08:40 UTC

Return-Path: <matthijs@pletterpet.nl>
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 9100312955F for <dnsop@ietfa.amsl.com>; Mon, 26 Jun 2017 01:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Y4bquPSO7at2 for <dnsop@ietfa.amsl.com>; Mon, 26 Jun 2017 01:40:02 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 8FDBD129466 for <dnsop@ietf.org>; Mon, 26 Jun 2017 01:40:02 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5Q8dol4026246 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Jun 2017 08:39:51 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v5Q8dn87004163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Jun 2017 08:39:50 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5Q8dkf9029014; Mon, 26 Jun 2017 08:39:48 GMT
Received: from [192.168.178.30] (/83.160.139.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Jun 2017 01:39:45 -0700
To: =?UTF-8?Q?Ond=c5=99ej_Caletka?= <Ondrej.Caletka@cesnet.cz>, Dick Franks <rwfranks@acm.org>, =?UTF-8?Q?=c3=93lafur_Gu=c3=b0mundsson?= <olafur@cloudflare.com>
Cc: 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>, RFC Editor <rfc-editor@rfc-editor.org>
References: <20170623105434.22478B810AB@rfc-editor.org> <CAN6NTqyBg74NF-F8imGiK0ArwxAbhc0uE_xXbX-No+Le8E9DUg@mail.gmail.com> <CAKW6Ri7npS57gupPrUc2aGhsg21u8csx+69GKrCFkeQ6H5Dnxw@mail.gmail.com> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl>
Date: Mon, 26 Jun 2017 10:39:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jyM3mGpN6Tyzg6QkQtDMfT-9Cec>
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: Mon, 26 Jun 2017 08:40:04 -0000

Hi,

On 24-06-17 17:45, Ondřej Caletka wrote:
> 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.

To be precise: We actually agreed that there should be *one field with 
the value of 0* 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 raised the specific issue because the to be RFC 8078 was going to 
change the CDS and CDNSKEY RDATA format from a fixed length RDATA to a 
variable length: In case of the DELETE operation, the Digest in 
presentation format was omitted.

While I agree with Paul in that thread that we should use all zeros for 
the DELETE operation, I believe it was an oversight that the proper 
encodings (hexadecimal, base64) should be used.

So to me this errata is valid.

Best regards,
   Matthijs


> I believe changing RRdata format just for this one purpose would add an
> unnecessary complexity.
> 
> --
> Best regards,
> Ondřej Caletka
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>