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

[Matthijs Mekking <[e-mail]>]

On 27-06-17 14:28, Dick Franks wrote:
> 
> On 26 June 2017 at 15:30, Matthijs Mekking <[e-mail]
> <mailto:[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?

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