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

From: RFC Errata System <[email-masked]>
Date: Fri, 23 Jun 2017 03:54:34 -0700 (PDT)

The following errata report has been submitted for RFC8078,
"Managing DS Records from the Parent via CDS/CDNSKEY".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5049

--------------------------------------
Type: Technical
Reported by: Ondřej Caletka <[email-masked]>

Section: 4

Original Text
-------------
   The contents of the CDS or CDNSKEY RRset MUST contain one RR and only
   contain the exact fields as shown below.

      CDS 0 0 0 0

      CDNSKEY 0 3 0 0

   The keying material payload is represented by a single 0.  This
   record is signed in the same way as regular CDS/CDNSKEY RRsets are
   signed.

   Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the
   DNSKEY algorithm is what signals the DELETE operation, but for
   clarity, the "0 0 0 0" notation is mandated -- this is not a
   definition of DS digest algorithm 0.  The same argument applies to
   "CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by
   [RFC4034], Section 2.1.2.

Corrected Text
--------------
   The contents of the CDS or CDNSKEY RRset MUST contain one RR and only
   contain the exact fields as shown below.

      CDS 0 0 0 00

      CDNSKEY 0 3 0 AA==

   The keying material payload is represented by a single octet with
   the value 00. This record is signed in the same way as regular
   CDS/CDNSKEY RRsets are signed.

   Strictly speaking, the CDS record could be "CDS X 0 X 00" as only the
   DNSKEY algorithm is what signals the DELETE operation, but for
   clarity, the "0 0 0 00" notation is mandated -- this is not a
   definition of DS digest algorithm 0.  The same argument applies to
   "CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by
   [RFC4034], Section 2.1.2.

Notes
-----
RFC 7344 defines both CDS and CDNSKEY record wire and presentation format to be identical to DS and DNSKEY wire and presentation format defined in RFC 4034.

In case of CDNSKEY record, RFC 4034 section 2.2 requires that:
> The Public Key field MUST be represented as a Base64 encoding of the Public Key.

As Base64 encoding encodes 6 bits into one character, one character alone can never be a valid Base64 sequence. The proper encoding of one-byte long sequence with binary value of 00 is AA==.

In case of CDS record, RFC 4034 section 5.3 requires that:
> The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits

Although the value of a single 0 fulfils this requirement per se, it's not properly parsable by many implementations since it is expected to be even number of hex digits to align with octet boundaries in the wire format. So proper form of CDS record should contain two zeroes in place of the digest.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8078 (draft-ietf-dnsop-maintain-ds-06)
--------------------------------------
Title               : Managing DS Records from the Parent via CDS/CDNSKEY
Publication Date    : March 2017
Author(s)           : O. Gudmundsson, P. Wouters
Category            : PROPOSED STANDARD
Source              : Domain Name System Operations
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Fri, 23 Jun 2017 12:37:45 +0100

The errata is correct.

Ólafur

sent from phone

On Jun 23, 2017 11:54, "RFC Errata System" <[email-masked]>
wrote:

> RFC 7344 defines both CDS and CDNSKEY record wire and presentation format
> to be identical to DS and DNSKEY wire and presentation format defined in
> RFC 4034.
>
> As Base64 encoding encodes 6 bits into one character, one character alone
> can never be a valid Base64 sequence. The proper encoding of one-byte long
> sequence with binary value of 00 is AA==.
>
> Although the value of a single 0 fulfils this requirement per se, it's not
> properly parsable by many implementations since it is expected to be even
> number of hex digits to align with octet boundaries in the wire format. So
> proper form of CDS record should contain two zeroes in place of the digest.
>
> Instructions:
> -------------

---

From: Dick Franks <[email-masked]>
Date: Sat, 24 Jun 2017 14:25:41 +0100

Comments in line below

> The errata is correct.

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.

A zone file parser is expected to recognise the zero algorithm field and
hence abstain from attempting to parse the non-existent key.

The fact that the placeholder is unparseable should be regarded not as an
error but a useful feature designed to root out under-performing zone file
parsers.

However, all of this confusion could have been avoided if RFC8078 had also
specified the corresponding RDATA wire format in each case.

Although this erratum should be rejected as it stands, it clearly does
identify an issue with RFC8078 which needs to be rectified at the earliest
opportunity.

--Dick

>> Although the value of a single 0 fulfils this requirement per se, it's
>> not properly parsable by many implementations since it is expected to be
>> even number of hex digits to align with octet boundaries in the wire
>> format. So proper form of CDS record should contain two zeroes in place of
>> the digest.
>>
>> Instructions:
>> -------------
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Ondřej Caletka <[email-masked]>
Date: Sat, 24 Jun 2017 17:45:47 +0200

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

---

From: Dick Franks <[email-masked]>
Date: Sun, 25 Jun 2017 19:19:00 +0100

On 24 June 2017 at 16:45, Ondřej Caletka <[email-masked]> wrote:

>8

> at all.

That does not appear to be the position at all.

RFC8078 mandates a specific presentation format notation for the entire
RDATA string whenever algorithm is zero, and irrespective of actual values
in other fields.

The RFC is conspicuously silent about the equivalent wire-format
representation.

This avoids the need of defining new format and updating all the
> zero is not conformant with currently defined presentation format of

It is clear from the text of draft-ietf-dnsop-maintain-ds-04 that the
notion of mandated presentation format notation was already present.
Moreover, that version also carried the warning:

    This is a change in format from strict interpretation of
    [RFC7344] and may cause problems with some deployed software.

Your primary argument was therefore a non-starter even before the
appearance of the unparseable single zero.

> unnecessary complexity.
>
> That train has already left the station.

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 25 Jun 2017 12:54:15 -0700

> the final "0" is a conventional token representing a zero-length key field.

Dick, can you give examples of that conventional token use?

--Paul Hoffman

---

From: Dick Franks <[email-masked]>
Date: Sun, 25 Jun 2017 23:30:27 +0100

On 25 June 2017 at 20:54, Paul Hoffman <[email-masked]> wrote:

> field.

This example is as good as any.

conventional:   established by custom or agreement

token:   a mark, sign or distinctive feature.

    [Chambers 21st Century Dictionary]

The token (final zero) is not in this case a self-defining term, but is
given meaning, or in this case lack of meaning, by the formal agreement
(RFC8078) that a zero algorithm field will completely define a DELETE
CDS/CDNSKEY RR.

--Dick

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 26 Jun 2017 10:39:41 +0200

Hi,

On 24-06-17 17:45, Ondřej Caletka wrote:
> https://mailarchive.ietf.org/arch/msg/dnsop/PsRIQOtd1bxFSEEm9lfv0WaHKeE >

To be precise: We actually agreed that there should be *one field with 
the value of 0* instead of no data at all.

> zero is not conformant with currently defined presentation format of

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

---

From: Jan Včelák <[email-masked]>
Date: Mon, 26 Jun 2017 11:59:04 +0200

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
<[email-masked]> wrote:
> To be precise: We actually agreed that there should be *one field with the
> value of 0* instead of no data at all.
>
> 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.
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 26 Jun 2017 07:26:58 -0400 (EDT)

On Mon, 26 Jun 2017, Jan Včelák wrote:

> was not specified in the document.

The reason we did not, was that we did not mean to have anything
"special" on either the presentation or the wire format, so there
was no need to specify a wire format. When Mathijs noticed it was
different, we added his disclaimer that the presentation format (and
thus wireformat) was different. Once we added the additional zeros,
we were no longer using a different format, so we removed that
disclaimer again. We thought we no longer asked something non-standard.

> long digests/keys as a request to remove the DS.

Yes that seems best. In fact, it could ignore the entire digest field
content when algorithm 0 is found.

And the cross this with another giant ietf-thread, that is a correct
application of the Postel Principle :P

Paul

---

From: Dick Franks <[email-masked]>
Date: Mon, 26 Jun 2017 12:29:25 +0100

> long digests/keys as a request to remove the DS.

Exactly!  The _only_ way to recognise DELETE CDS/CDNSKEY is the zero
algorithm field. RFC8078 says that.  All the rest is mere decoration.

---

From: Dick Franks <[email-masked]>
Date: Mon, 26 Jun 2017 12:29:57 +0100

On 26 June 2017 at 09:39, Matthijs Mekking <[email-masked]> wrote:

> length: In case of the DELETE operation, the Digest in presentation format

CDS and CDNSKEY are both variable length. There is no length component in
the RDATA itself. The length of the digest (or key) is calculated (RDLENGTH
- 4) so whether there is one byte or none at all makes not a scrap of
difference. So that explanation can be dismissed immediately.

> (hexadecimal, base64) should be used.

Not just an oversight. Now it is an oversight baked into an IESG approved
standards track document.

So an implementer has little choice but to make CDS/CDNSKEY work in
accordance with the standard as written until IESG approves something else.

And when that something else arrives, users will be mightily upset if
RFC8078 CDS/CDNSKEY suddenly stops working, so the code will need to cope
with both versions.  The only realistic way to achieve that is to determine
the entire content of the DELETE CDS/CDNSKEY from the zero algorithm field.
Beyond that, the content of the "mandated notation" is irrelevant because
it can be left unparsed.

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 26 Jun 2017 16:30:32 +0200

On 26-06-17 13:29, Dick Franks wrote:
> 
> On 26 June 2017 at 09:39, Matthijs Mekking <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     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
> CDS and CDNSKEY are both variable length. There is no length component 
> in the RDATA itself. The length of the digest (or key) is calculated 
> (RDLENGTH - 4) so whether there is one byte or none at all makes not a 
> scrap of difference. So that explanation can be dismissed immediately.

You misunderstood: Variable length in octets, but not variable in number 
of RDATA elements.

>     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.
> 
> 
> Not just an oversight. Now it is an oversight baked into an IESG 
> approved standards track document.
> 

Sure, but that is why we are discussing it, not?

> RFC8078 CDS/CDNSKEY suddenly stops working, so the code will need to 
> cope with both versions.  The only realistic way to achieve that is to 
> determine the entire content of the DELETE CDS/CDNSKEY from the zero 
> algorithm field. Beyond that, the content of the "mandated notation" is 
> irrelevant because it can be left unparsed.

My first suggestion for the draft was indeed: In case the DNSSEC 
algorithm is 0, the Digest/Public Key MUST be ignored.

But there were concerns that if someone mistyped the algorithm field the 
DS accidentally gets removed. So now the RFC says that the contents of 
the CDS or CDNSKEY RRset MUST contain one RR and the "0 [0,3] 0 0" 
notation is mandated.

Best regards,
   Matthijs

---

From: Dick Franks <[email-masked]>
Date: Tue, 27 Jun 2017 13:28:40 +0100

On 26 June 2017 at 15:30, Matthijs Mekking <[email-masked]> wrote:

> of RDATA elements

I did.

Am I correct in thinking that you want some acknowledgement that 4 fields
exist, but do not really care what the final item is?

> Sure, but that is why we are discussing it, not?

That is what we should be discussing, but this erratum seems to be steering
us along a road full of potholes that I certainly do not want to fall into.
IMHO this is based on a misunderstanding of your "mandated notation"
argument.

> My first suggestion for the draft was indeed: In case the DNSSEC algorithm
> is 0, the Digest/Public Key MUST be ignored.
>

I would go further, and say that all fields (except algorithm) MUST be
ignored

> DS accidentally gets removed. So now the RFC says that the contents of the
> CDS or CDNSKEY RRset MUST contain one RR and the "0 [0,3] 0 0" notation is
> mandated.
>

The one RR requirement is not in dispute.

Let us make a start with the following 3 use cases, to see if we can come
to some common understanding of what we are trying to achieve.

(1)  CDS arrives on the wire

cds.example. IN CDS  \# 5 1234 00 56 78      ; silly numbers in most fields

RDATA as received:

         'algorithm' => 0,
         'digestbin' => 'x',
         'digtype' => 86,
         'keytag' => 4660,

Algorithm = 0, so presentation format uses "RFC8078 mandated notation":

cds.example.    IN    CDS    0 0 0 0

(2)  DELETE CDS read from zone file, transmitted to parent

cds.example.    IN    CDS    0 0 0 0

Algorithm = 0, so this is a DELETE CDS.

Check that RDATA string matches "mandated notation".

Coerce all RDATA numerical fields to zero, digest empty.

Transmitted CDS RR:

cds.example. IN CDS  \# 4 0000 00 00

(3)  Normal CDS read from zone file, but with accidental 0 in algorithm
field

cds.example. CDS 6485 0 1 2bb183af5f22588179a53b0a98631fad1a292118

Algorithm = 0, so this is apparently a DELETE CDS.

Exception raised - RDATA does not match "mandated notation"

DS saved from accidental deletion:-)

Obviously, similar logic applies to CDNSKEY.

--Dick

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Jun 2017 00:54:52 +1000

And in reality it will be something like for CDS:

if (validated && rrset_count == 1 &&
    rdata->len >= 4 && !memcmp(rdata->data, "\0\0\0", 4))
	remove_ds();

because this will all be done in wire format.  Note the above ignores
the hash content for the CDS if any.  The problem is that we do not
have a well defined wire format for this signal.

"The keying material payload is represented by a single 0."  The
quoted sentence does not make sense.  I can think of 3 interpretions
of that sentence.

1.  the zero is a place holder for zero length field.
2.  the field is a zero byte.
3.  the field can be any non zero length content but we
    are showing it as a zero as it is to be ignored.

Remember this record has to be written out and read back in by slave
servers across restarts.  They MUST *all* produce the same wire
representation or else the returned rrset will not validate.

Mark

In message <[email-masked]>, Dick Franks wr
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jan Včelák <[email-masked]>
Date: Tue, 27 Jun 2017 19:10:01 +0200

I'm not sure if this discussion is moving forward.

CDS/CDNSKEY RDATA format is the same as DS/DNSKEY RDATA format per
definition in Section 3 of RFC 7344. Although DS Digest field and
DNSKEY Public Key field can be zero-length on wire, the presentation
format is underspecified and it practically cannot be used in this
case. That is a problem in implementations where presentation format
is used (e.g. in zone file). And we have already confirmed existence
of this problem in some implementations in this very thread.

This erratum makes a simple change that as a result gives one clear
interpretation of how the DS DELETE request should look like. And it
allows CDS/CDNSKEY record for the request to be specified both in wire
and presentation format.

There is plenty other alternative ways to express DS DELETE request.
But I would prefer accepting this simple erratum rather than
researching all the other options (which we should have done when
revising the drafts of this document).

Jan

---

From: Dick Franks <[email-masked]>
Date: Tue, 27 Jun 2017 19:38:55 +0100

> revising the drafts of this document).

There is no point in moaning that things could/should have been done better.

What is needed now is methodical use-case analysis based on RFC8078 as it
exists now and tested against a real implementation.  The time to rewrite
the RFC will come if/when we discover we are unable to live with it. We
have not reached that point yet.

--Dick

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Jun 2017 14:21:27 +1000

> have not reached that point yet.

I can't go from RFC8078 to a working implementation because the
existing description is not clear enough to do it.  I don't think
anyone can do it.

With the proposed errata fix I could write code.  For CDS the RRset
is a single RR with a rdata of 0x00 0x00 0x00 0x00 0x00.  For CDNSKEY
the RRset is a single RR with a rdata of 0x00 0x03 0x00 0x00 0x00.

In both cases the RRset needs to be signed and validitation needs
to return that the answer is secure before it can be acteded on.

Mark

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 28 Jun 2017 10:01:25 +0200

On 27-06-17 14:28, Dick Franks wrote:
> 
> On 26 June 2017 at 15:30, Matthijs Mekking <[email-masked]
>     You misunderstood: Variable length in octets, but not variable in
>     number of RDATA elements
> 
> 
> I did.
> 
> Am I correct in thinking that you want some acknowledgement that 4
> fields exist, but do not really care what the final item is?

RFC 7344 specifies that the CDS RDATA format is the same as DS RDATA
format. RFC 4034 speficies the DS RDATA format contains 4 fields. So by
definition the CDS RDATA contains 4 fields. Same logic applies for
DNSKEY/CDNSKEY.

I suggested indeed one time that we should ignore the Digest (or Public
Key in case of CDNSKEY) if Algorithm is 0, but that is unrelated to this
issue. Since "0" is not valid base64, I would like to see this erratum
accepted to fix the notation in RFC 8078.

Best regards,
  Matthijs

>         So an implementer has little choice but to make CDS/CDNSKEY work
>         in accordance with the standard as written until IESG approves
>         something else.
> 
> 
> That is what we should be discussing, but this erratum seems to be
> steering us along a road full of potholes that I certainly do not want
> to fall into. IMHO this is based on a misunderstanding of your "mandated
> notation" argument.
>  
>  
> 
>         And when that something else arrives, users will be mightily
>         upset if RFC8078 CDS/CDNSKEY suddenly stops working, so the code
>         will need to cope with both versions.  The only realistic way to
>         achieve that is to determine the entire content of the DELETE
>         CDS/CDNSKEY from the zero algorithm field. Beyond that, the
>         content of the "mandated notation" is irrelevant because it can
>         be left unparsed.
> 
> 
>     But there were concerns that if someone mistyped the algorithm field
>     the DS accidentally gets removed. So now the RFC says that the
>     contents of the CDS or CDNSKEY RRset MUST contain one RR and the "0
>     [0,3] 0 0" notation is mandated.
> 
> 
> Let us make a start with the following 3 use cases, to see if we can
> come to some common understanding of what we are trying to achieve.
>

---

From: Ondřej Caletka <[email-masked]>
Date: Wed, 28 Jun 2017 13:00:26 +0200

Hello,

I have an erratum to this reported erratum. This proposed corrected

should actually look like this (difference is the first CDS example):

>    Strictly speaking, the CDS record could be "CDS X 0 X X" as only the

Otherwise, the statement "only the DNSKEY algorithm is what signals the
DELETE operation" would not make any sense.

--
Regards,
Ondřej Caletka

---

From: Ondřej Caletka <[email-masked]>
Date: Wed, 28 Jun 2017 13:27:03 +0200

Hello,

>Dick Franks:
> the RRset is a single RR with a rdata of 0x00 0x03 0x00 0x00 0x00.

I have a confirmation from the real implementation of RFC8078 in the .CZ
domain registry (cc jaromir.talir) that their understanding of CDNSKEY
DELETE operation is exactly the set of RDATA quoted by Mark Andrews,
which translates to the presentation form CDNSKEY 0 3 0 AA==

I don't think there is a big room to interpret RFC 8078 differently,
since it does not define any new presentation/wire format for
CDS/CDNSKEY record. Therefore, even future versions of software that
(de-)serializes RRs between wire and presentation format will have
issues if there are not all fields mandated by RFC 4034 present in the
rdata.

--
Ondřej Caletka