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

[Jan Včelák <[e-mail]>]

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
<[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop