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

Jan Včelák <jv@fcelda.cz> Mon, 26 June 2017 09:59 UTC

Return-Path: <jv@fcelda.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 69083129A97 for <dnsop@ietfa.amsl.com>; Mon, 26 Jun 2017 02:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.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 j0qZopBpAxvb for <dnsop@ietfa.amsl.com>; Mon, 26 Jun 2017 02:59:26 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE489128A32 for <dnsop@ietf.org>; Mon, 26 Jun 2017 02:59:25 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id y70so37023161vky.3 for <dnsop@ietf.org>; Mon, 26 Jun 2017 02:59:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+SuJiI7cggwe84g2zcNQu8ZHsuZm6SrRKmEk+KIOZE4=; b=IsjwY9Rekq85NYovtP2IJ3p/e0eNJsT84wgg5j1MSgxRXJx7H9bZ840CbFmeMsBFry tgmZTyBsEXfQvedArBmWwHu3F9fFQWinBhqUa0GemXTP9HIrUq31pvrwCvLdsAW/mRr4 gptVmA3yC705L/WkEgmsepSzJlEdkcoyrunG4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+SuJiI7cggwe84g2zcNQu8ZHsuZm6SrRKmEk+KIOZE4=; b=gz1q7VNnTtp/AxAarLU8dHHRIYjN4vx+XEsNxS3HMStluEroBiQZ0flWkCsxr1VUj6 frsQv9svlQr7hFwsQ2+3560eiUOcHxETlvRaIAGttwqtHnxjVDAz/79YhOhaS4niy+Ey GlGcMlsgpOmA6xWy9l3ZW5zhS3zopaA6i75f5/UNs4x/PZkwgSaqtdFxcXKuTeu+IzR0 4yJroYWWLzkVkgonA3GyuwUvyAz6oNX+t4MOPlR/18EyHBSpV+kiUvHzbGJqdNwJtmhI 7vaYODhh5bfNkR/onkU3bvAvxCQdymf+mp4/yAh73JNxUXt8dKSOxQ6q11pOZjl8IRTa ar/w==
X-Gm-Message-State: AKS2vOzs1DBxyRyXWRDFe4MO8sU78Rl6FDhCFwiqnsTj8eg3SPU0UpV6 hmIW36Da+sQEsD52IR2S1JyX7GjVJoUu
X-Received: by 10.31.36.19 with SMTP id k19mr9385781vkk.78.1498471164685; Mon, 26 Jun 2017 02:59:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.89.92 with HTTP; Mon, 26 Jun 2017 02:59:04 -0700 (PDT)
X-Originating-IP: [94.112.122.95]
In-Reply-To: <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl>
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> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl>
From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= <jv@fcelda.cz>
Date: Mon, 26 Jun 2017 11:59:04 +0200
Message-ID: <CAM1xaJ9F91s9+O1CtwApdOq_5DorMU3SXSvZajGAdGV1h0oHFg@mail.gmail.com>
To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>
Cc: =?UTF-8?Q?Ond=C5=99ej_Caletka?= <Ondrej.Caletka@cesnet.cz>, Matthijs Mekking <matthijs@pletterpet.nl>, Dick Franks <rwfranks@acm.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>, RFC Editor <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vi2T9rNPfOLIKuylWWXi03lAZeI>
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 09:59:28 -0000

I agree that the errata is correct.

It is maybe suboptimal that wire format for DS/DNSKEY delete-request
was not specified in the document. And I'm not sure if the authors
meant that the digest/public key is zero-length or one-byte long. But
luckily this can prevent some compatibility issues:

Presentation format for DS/CDS just doesn't expect zero-length digest
(as opposed to NSEC3PARAM which uses dash instead of the hex encoded
salt if the salt is zero-length). I tried with Knot DNS and BIND -
both can write DS record in presentation format with zero-length
digest but cannot parse it back. (Try it yourself with
"delete-cds.example.test. IN TYPE59 \# 4 00000000". I haven't trie
with DNSKEY but I expect the problem will be the same.)

The implementers should be careful and avoid the trouble. In this
sense, I think parent zone should accept both zero-length and one-byte
long digests/keys as a request to remove the DS.

Jan

On Mon, Jun 26, 2017 at 10:39 AM, Matthijs Mekking
<matthijs@pletterpet.nl> wrote:
> 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
>>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop