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

[Mark Andrews <[e-mail]>]

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 <[e-mail]>, Dick Franks wr
ites:
> 
> On 26 June 2017 at 15:30, Matthijs Mekking <[e-mail]> 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: [phone]                 INTERNET: [e-mail]