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

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

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

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

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

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 >

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

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

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

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

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

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

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

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 c

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

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

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

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 real

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

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

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

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

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

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/CDN

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

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 speci

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

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: Pre

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

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 specif

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

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 con

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

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

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

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 presentatio

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

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

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

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 sp

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

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 an

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

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 Reporte