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

[Warren Kumari]

Hi all,

I gave this discussion some time to converge[0], and also asked for
more comments during the (2nd) DNSOP session in Prague.

Unless I hear strong objections by Wednesday I'll mark the errata as
verified (with the minor clarification provided):
Strictly speaking, the CDS record could be "CDS X 0 X X" 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.


W
[0]: Yeah, that sounds much better than "procrastinated" :-)


On Wed, Jun 28, 2017 at 7:27 AM, Ondřej Caletka
 wrote:
> Hello,
>
>>Dick Franks:
>>> 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.
> Mark Andrews:
>> 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.
>
> 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
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Caletka]

Hello,

>Dick Franks:
>> 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.
Mark Andrews:
> 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.

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



smime.p7s
Description: Elektronicky podpis S/MIME
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Caletka]

Hello,

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

>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.

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
>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.

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

--
Regards,
Ondřej Caletka





smime.p7s
Description: Elektronicky podpis S/MIME
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

On 27-06-17 14:28, Dick Franks wrote:
> 
> On 26 June 2017 at 15:30, Matthijs Mekking  > wrote:
> 
> 
> 
> On 26-06-17 13:29, Dick Franks wrote:
> 
> 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.
> 
> 
> 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.
>  
>  
> 
> 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.
> 
> 
> 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
> 
>  
> 
> 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.
> 
> 
> 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.INCDS0 0 0 0

> (2)  DELETE CDS read from zone file, transmitted to parent
> 
> cds.example.INCDS0 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  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

In message 
, Dick 
Franks writes:
> On 27 June 2017 at 18:10, Jan Včelák  wrote:
>
> >8
>
> 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).
> >
>
> 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.

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

> --Dick
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On 27 June 2017 at 18:10, Jan Včelák  wrote:

>8

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).
>

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jan Včelák]

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


On Tue, Jun 27, 2017 at 4:54 PM, Mark Andrews  wrote:
>
> 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 
> , Dick 
> Franks wr
> ites:
>>
>> On 26 June 2017 at 15:30, Matthijs Mekking  wrote:
>>
>> >
>> >
>> > On 26-06-17 13:29, Dick Franks wrote:
>> >
>> > 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?
>>
>>
>> So an implementer has little choice but to make CDS/CDNSKEY work in
>> >> accordance with the standard as written until IESG approves something 
>> >> else.
>> >>
>> >
>> > 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.
>>
>>
>>
>> > 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.
>> >>
>> >
>> > 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
>>
>>
>>
>> > 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.
>> >
>>
>> 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.INCDS0 0 0 0
>>
>>
>> (2)  DELETE CDS read from zone file, transmitted to parent
>>
>> cds.example.INCDS0 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  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

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

[Mark Andrews]

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 
, Dick 
Franks wr
ites:
> 
> On 26 June 2017 at 15:30, Matthijs Mekking  wrote:
> 
> >
> >
> > On 26-06-17 13:29, Dick Franks wrote:
> >
> > 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?
> 
> 
> So an implementer has little choice but to make CDS/CDNSKEY work in
> >> accordance with the standard as written until IESG approves something else.
> >>
> >
> > 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.
> 
> 
> 
> > 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.
> >>
> >
> > 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
> 
> 
> 
> > 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.
> >
> 
> 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.INCDS0 0 0 0
> 
> 
> (2)  DELETE CDS read from zone file, transmitted to parent
> 
> cds.example.INCDS0 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  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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On 26 June 2017 at 15:30, Matthijs Mekking  wrote:

>
>
> On 26-06-17 13:29, Dick Franks wrote:
>
> 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?


So an implementer has little choice but to make CDS/CDNSKEY work in
>> accordance with the standard as written until IESG approves something else.
>>
>
> 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.



> 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.
>>
>
> 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



> 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.
>

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.INCDS0 0 0 0


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

cds.example.INCDS0 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  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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

On 26-06-17 13:29, Dick Franks wrote:


On 26 June 2017 at 09:39, Matthijs Mekking > wrote:


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.


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.


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


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

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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On 26 June 2017 at 09:39, Matthijs Mekking  wrote:

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.
>

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.


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.

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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On 26 June 2017 at 10:59, Jan Včelák  wrote:

>8

>
> 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.
>

Exactly!  The _only_ way to recognise DELETE CDS/CDNSKEY is the zero
algorithm field. RFC8078 says that.  All the rest is mere decoration.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

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


It is maybe suboptimal that wire format for DS/DNSKEY delete-request
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.


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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jan Včelák]

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 ". 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
 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

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

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

[Dick Franks]

On 25 June 2017 at 20:54, Paul Hoffman  wrote:

> On 24 Jun 2017, at 6:25, Dick Franks wrote:
>
> > 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.
>
> Dick, can you give examples of that conventional token use?
>

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On 24 Jun 2017, at 6:25, Dick Franks wrote:

> 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.

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

--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

 On 24 June 2017 at 16:45, Ondřej Caletka  wrote:

>8

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.


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
> 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.
>

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.


I believe changing RRdata format just for this one purpose would add an
> unnecessary complexity.
>
> That train has already left the station.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Caletka]

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



smime.p7s
Description: Elektronicky podpis S/MIME
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

 Comments in line below

On 23 June 2017 at 12:37, Ólafur Guðmundsson  wrote:

> 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



On Jun 23, 2017 11:54, "RFC Errata System" 
> wrote:
>
>> 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 
>>
>> 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
>>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailma

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

[Ólafur Guðmundsson]

The errata is correct.

Ólafur

sent from phone

On Jun 23, 2017 11:54, "RFC Errata System" 
wrote:

> 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 
>
> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[RFC Errata System]

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 

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop