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