Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

["John Levine" <[e-mail]>]

In article <[e-mail]> 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