In article <c4eb59c4-ea83-4dbe-84d0-d8d43735b...@verisign.com> you write: >I am reluctant to add this. As John said, I think it won't age well. I think >there is no obvious size at which to make >a recommendation. For uses cases such as CZDS / zone file access, I see no >harm at all to add ZONEMD for even very large >zones. What might be missing is a paragraph that says those that publish >ZONEMD records need to be aware of the possible >consequences it would have on the consumers of their zone data.
Perhaps rather than going in circles about this, you could offer some advice on how to estimate how long computing and verifying the signature is likely to take. For signing, I'd think that once you have the zone signed, it should be in the correct order and it's a linear pass over the zone to compute the signature. If your DNSSEC signing software is amenable, you might as well do them both at the same time. For verifying, it's a potential N log N sort of the zone isn't in canonical order, then a linear pass over it. Then wave your hands and say if you can't do all that fast enough, perhaps you should refrain from signing and/or verifying the zone, keeping in mind that "fast enough" is totally subjective and dependent on the situation. >The current text was agreed to during earlier working group discussion. The >problem with "ignore" (as John points out) >is that it could mean the non-apex RR should be omitted from the zone. > >At one point the document said that non-apex ZONEMD was forbidden, with the >implication that if found the whole zone >should be rejected. Similar to what you might do with a non-apex SOA. But >that seemed pretty harsh and in the end we >settled on the current text. I'd suggest going back to MUST NOT. Yes, it's harsh, but if someone is sticking a ZONEMD in the middle of the zone, something is wrong and as I keep saying, I'd rather not try to guess how to kludge around someone else's mistake. >> 8) 3.4.1, there is no reason whatsoever to make the setting of the parameter >> field a SHOULD here. MUST is correct. > >As I said above I'm willing to make this a MUST, but I disagree there are no >reasons whatsoever. > >I think one legitimate reason would be to avoid ossification, or what I think >they call GREASE in the TLS world. Grease is fine but in that case I'd change the language to make it clear that the parameter field is an arbitrary value included in the hash. That means you can now have two different valid SHA384-SIMPLE ZONEMDs with same serial and digest type which doesn't obviously break anything but makes me nervous. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
