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