On 26-06-17 13:29, Dick Franks wrote:
On 26 June 2017 at 09:39, Matthijs Mekking <matth...@pletterpet.nl
<mailto:matth...@pletterpet.nl>> wrote:
I raised the specific issue because the to be RFC 8078 was going to
change the CDS and CDNSKEY RDATA format from a fixed length RDATA to
a variable length: In case of the DELETE operation, the Digest in
presentation format was omitted.
CDS and CDNSKEY are both variable length. There is no length component
in the RDATA itself. The length of the digest (or key) is calculated
(RDLENGTH - 4) so whether there is one byte or none at all makes not a
scrap of difference. So that explanation can be dismissed immediately.
You misunderstood: Variable length in octets, but not variable in number
of RDATA elements.
While I agree with Paul in that thread that we should use all zeros
for the DELETE operation, I believe it was an oversight that the
proper encodings (hexadecimal, base64) should be used.
Not just an oversight. Now it is an oversight baked into an IESG
approved standards track document.
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?
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.
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.
Best regards,
Matthijs
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
