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

[Michael StJohns <[e-mail]>]

On 1/5/2020 2:00 PM, John Levine wrote:
> In article <[e-mail]> you write:
>> 1) A recommendation for the maximum size of the zone (and for that
>> matter the maximum churn rate). This is hinted at in the abstract, but
>> missing from the body of the document.
> I don't get it.  The draft makes it clear that ZONEMD in this
> implementation is intended for statically signed zones.  If Verisign
> wants to put a ZONEMD in the daily download of the three hundred
> million record .com zone file, I think that would be dandy.  If your
> zone of whatever size is updated too often to deal with recomputing
> ZONEMD, then don't.

To quote one of my favorite movies:  " I don't think that means what you 
think it means"

The abstract text which is usually not considered normative says:

>     As specified at this time, ZONEMD is not designed for use in large,
>     dynamic zones due to the time and resources required for digest
>     calculation.  The ZONEMD record described in this document includes a
>     field intended to enable future work to support large, dynamic zones.

Define: "Large" and define "Dynamic"  and define "large AND dynamic".   
A large fairly static zone (e.g. 100K records with changes once a month) 
might be a candidate.  A small dynamic zone (e.g 20 records changing 
hourly) might also be a candidate.

> Also, advice about what's too big or too slow doesn't age well.  I
> expect most of use remember a time when the idea of a million record
> zone file seemed absurd.

Tim represented that "the authors feel they've performed their 
experiments" and I would assume that the experiments have given them 
some ideas on which zone size and churn don't cause problems.  E.g. how 
long does it take to canonicalize and hash various sizes of zones given 
a particular (or several different) hardware implementation(s)?


>
>
>> 2) For each of the use cases, an explanation of how this RRSet actually
>> mitigates or solves the identified problem.
> I don't get this either.  ZONEMD lets you verify that you got the
> entire zone correctly.  If anything, I'd take most of this section out
> since the list of places where people get zone files isn't likely to
> age well either.

Let's take one example:

>   As the
>     root zone spreads beyond its traditional deployment boundaries, the
>     need for verification of the completeness of the zone contents
>     becomes increasingly important.

I read this (and the motivation section), and I still don't know why 
this is a problem.   Nor what the receiver of the zone should do if it 
detects "missing" data for some definition of missing.

(Note that the "parent tells you whether the child has a zonemd record" 
thing won't work here, so it's going to have to be some sort of 
configuration option for the receiver to tell it what to do - e.g. pull 
it again, yell at the root signers???).

1.3.4 comes the closest to specifying a real use.  The rest - not so 
much.  1.3.3 basically seems to be saying - RPZ didn't do it right and 
rather than fixing it by checking DNSSEC, do this instead.


>
>>>      This specification utilizes ZONEMD RRs located at the zone apex.
>>>      Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
>>>      specification.
>> Instead - "non-apex ZONEMD RRs MUST be ignored by the receiving client".
> Does ignore mean they aren't included in the computation of an apex ZONEMD?  Ugh.
>
> ZONEMD RRs MUST NOT appear anywhere other than the apex of a zone.

What does a client do if it sees a non-apex ZONEMD RR because someone 
will put it there?  E.g. it "ignores it as a verifiable item".  The rest 
of the processing rules apply.


>
>>>      A zone MAY contain multiple ZONEMD RRs to support algorithm agility
>>>      [RFC7696] and rollovers.  Each ZONEMD RR MUST specify a unique Digest
>>>      Type and Parameter tuple.
>> "A client that receives multiple ZONEMD RRs with the same DT and
>> Parameter MUST try to verify each in turn and MUST accept the zone if
>> any verify".
> I think that's an error.  If they have the same DT and parameter, either they
> have the same serial and they're duplicates, or one of them is obsolete.

Yup.  Or the zone issuer failed to update the serial number... know any 
zones (or more to the point zone operators) like this?


>
>>>    It is RECOMMENDED that a zone include only
>>>      one ZONEMD RR, unless the zone publisher is in the process of
>>>      transitioning to a new Digest Type.
>> Lower case "recommended" here please.
> I'd take it out altogether.  What problem does multiple signatures cause?
>
> Agree with most of the other editorial advice.
>
>> 13) Missing a section 4.2 which says what you do when a zone doesn't
>> verify.  Otherwise, what's the point?
> That seems extremely dependent on the context.  What I would do on a
> secondary name server AXFR'ing a zone for which it's authoritative vs.
> one of the thousand daily CZDS zip file downloads is rather different.

If a computer can't figure out what to do with a failed validation 
absent human interaction then you might as well say:

"ZONEMD RRs may be safely ignored by all but the geekiest of DNS human 
operators as there is no guidance on what to do if you see a zone that 
appears to be incomplete due to ZONEMD RR validation as it might not 
actually be incomplete"


>
> With respect to updated zones, perhaps it should say that if zone
> updates are distributed with IXFR, each update should either have an
> updated ZONEMD with the new checksum for the full zone or delete the
> now obsolete old ZONEMD.  That seems obvious, but you never know.

Humans do stupid things, and tools don't always prevent them from doing 
so.  DNS is both a transport/query protocol and a data protocol, and the 
data protocol is subject to some really interesting constraints that are 
easily evaded by human error or intention.

The check on the data protocol is what the client/receiver does with it 
in the face of errors.

Later, Mike


>
> R's,
> John