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 <ma...@isc.org> 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 > <cakw6ri55omz2zo27xvneeytqscx6hjk+vqte7p8dyv53uq0...@mail.gmail.com>, Dick > Franks wr > ites: >> >> On 26 June 2017 at 15:30, Matthijs Mekking <matth...@pletterpet.nl> 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. 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 > -- > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
