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

From: Tim Wicinski <[email-masked]>
Date: Sat, 4 Jan 2020 17:30:23 -0500

All,

The chairs would like to welcome the new year with some work.
The authors and chairs feel this document is ready to move forward.

One thing to note: This document has the status "Experimental", but
the authors feel they've performed their experiments and their current
status is "Standards Track".

This starts a Working Group Last Call for "Message Digest for DNS Zones"

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/

The Current Intended Status of this document is: *Standards Track*
Please speak out if the intended status seems incorrect.

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication,
please speak out with your reasons.

This starts a two week Working Group Last Call process, and ends on:
18 January 2020

thanks
tim

---

From: Michael StJohns <[email-masked]>
Date: Sat, 4 Jan 2020 20:14:17 -0500

Hi Tim et al -

I read through this back a few versions ago and mostly thought it 
harmless as an experimental RFC.  I'm not sure that it's quite ready for 
prime time as a Standards track RFC.

Here's what I think is missing:

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.
2) For each of the use cases, an explanation of how this RRSet actually 
mitigates or solves the identified problem.  E.g. at least a paragraph 
each for each the subsections of 1.3. That paragraph should lay out why 
the receiver of the zone should actually want to do this verification 
and the cost/benefit of that for the end user.
3)   Section 2 uses SHOULD or MUST related to data content rather than 
protocol.   That's a problem in that humans are notorious for making 
mistakes and screwing up the records.

>   This section describes the ZONEMD Resource Record, including its
>     fields, wire format, and presentation format.  The Type value for the
>     ZONEMD RR is 63.  The ZONEMD RR is class independent.  The RDATA of
>     the resource record consists of four fields: Serial, Digest Type,
>     Parameter, and Digest.
>
>     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".
>
>     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".
and "If there are multiple ZONEMD RRs with distinct DT and Parameters, 
the zone is acceptable if the client can verify at least one of those RRs"
>   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.

4) 2.1.3 - The parameter field MUST be set to 0 for SHA384-SIMPLE on 
creation, and the client MUST NOT accept the RR if this field is not set 
to zero for SHA384-SIMPLE.

5) 3.1.2 - This is I believe different than how DNSSEC does it?  If it's 
the same, then this is fine, otherwise this protocol should be 
calculating the RRSet wire representation the same as DNSSEC does it.

6) 3.2 - another set of data set MUSTs (the recommended isn't an issue, 
but should probably be lower case) that need guidance for the accepting 
client if the MUST doesn't hold because of human error.

7) 3.3 - Probably lower case may for DNSSEC.    The rest of this is 
operational guidance that really doesn't give anything useful for the 
protocol.

8) 3.4.1, there is no reason whatsoever to make the setting of the 
parameter field a SHOULD here.  MUST is correct.

9) 3.4.2 - Third bullet.  See above and also, as currently written here 
this implies you ignore ALL RRs at that owner/class/type/RDATA if there 
are duplicates.  Rephrase at least.

10) 3.5 - This section needs a bit of re-working.  Generally, what you 
want to say is that if you have ZONEMD RRs, that they have to be 
published at the same time as the matching SOA.  You also want to 
probably make a note somewhere that if the SOA and ZONEMD RR do not 
match on receipt you do ... something?  Not sure what.

11) I really need to write an RFC on "SHOULD considered harmful (if not 
qualified)".   For section 4, bullet 1 - explain what you mean by SHOULD 
- e.g. is this a configuration option, or a implementation option.  If a 
configuration option, in which case might a recipient not want to do 
this?  If an implementation option, why isn't this a MUST?  Also, if you 
don't do the DNSSEC thing, identify the next step to be executed (i.e. 4).

11.1) Sorry for the numbering - missed step 4 in section 4 - see point 3 
and reconcile or remove 3rd and subsequent paras from section 2 to make 
this section the only normative one.

12) 4.1 vs my point 3 above - reconcile, or remove 3rd and subsequent 
paras from section 2 to make this section the only normative one.

13) Missing a section 4.2 which says what you do when a zone doesn't 
verify.  Otherwise, what's the point?

14) Section 6.1, third paragraph is incorrect.  Note that Section 4 step 
2 is part of the stuff that's skipped if the zone is provably insecure 
or if you decide that SHOULD means "I'm lazy and I don't want to do 
it".  E.g. Section 4 does not "REQUIRE" this because of the preceding  
and enclosing "RECOMMENDED".

15) Add a section 6.3 to security considerations which describe the 
downsides of this RR - e.g. for example that it can make a zone more 
fragile by requiring complete coherence in the zone and that this is a 
substantial change both to DNSSEC and the original design of DNS.  Or 
when applied to a large dynamic zone may never be able to calculate a 
valid digest in time, nor have a recipient accept it.

I think Experimental is fine.  I'm not sure without a clear text 
addressing my points 1,2, 13 and 15 that this is useful as a standards 
track document for general use.

Later, Mike

On 1/4/2020 5:30 PM, Tim Wicinski wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Sun, 05 Jan 2020 02:39:03 +0000

On Sunday, 5 January 2020 01:14:17 UTC Michael StJohns wrote:
> ...
> 2) ...
> 3) ...
> ...

i agree, and especially regarding point 1. without a block hash technique 
whereby the zonemd can be incrementally updated upon receipt of changes by 
UPDATE and IXFR (in some canonical form so that such updates are the same 
regardless of the source of the change which may be UPDATE, IXFR, or other), 
there is a broad spectrum of zone sizes and churn rates for which ZONEMD as 
specified is not applicable.

these limits should be described, and the above block hash methodology should 
be hinted at as "for future work, to eliminate those limitations."

-- 
Paul

---

From: "John Levine" <[email-masked]>
Date: 5 Jan 2020 14:00:35 -0500

>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.

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.

>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.

>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.

>Parameter MUST try to verify each in turn and MUST accept the zone if 

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.

>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.

>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.

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.

R's,
John

---

From: Michael StJohns <[email-masked]>
Date: Sun, 5 Jan 2020 16:17:38 -0500

> zone of whatever size is updated too often to deal with recomputing

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.

> expect most of use remember a time when the idea of a million record

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)?

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.

> 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.

> 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?

> 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"

> 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

---

From: "John R Levine" <[email-masked]>
Date: 5 Jan 2020 18:29:09 -0500

We seem to have a fairly basic disagreement here about whether we can 
expect people who implement ZONEMD to be familiar with the way that DNS 
servers work.  In pretty much all of the cases below, it seems to me that 
if the answer to the question isn't obvious, you're not the audience for 
this document.

On Sun, 5 Jan 2020, Michael StJohns wrote:

> 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.
>
> 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)?
>> 
> 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.
>
>
>>
> 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.

MUST NOT means it doesn't matter.  A zone with a non-apex ZONEMD does not 
implement this spec, so it's not useful to try and guess what the person 
who created the zone got wrong.  It's more or less the same as what do you 
do with a record that has a compressed name that points past the end pf 
the message -- it's just wrong.

>> 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?

See above -- it's broken.  I don't think at this late stage that it is a 
good idea try and guess how people will screw things up and to propose 
kludges to guess what they meant.

> If a computer can't figure out what to do with a failed validation absent 
> human interaction then you might as well say:
>
> appears to be incomplete due to ZONEMD RR validation as it might not actually 
> be incomplete"

It's exactly the same thing you'd say about any other zone that has 
techincal errors.  I don't see anything new here.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2020 12:13:26 -0500

>appears to be incomplete due to ZONEMD RR validation as it might not 

Well, OK, here's a concrete example.  I download the COM zone every
day from Verisign, and also a separate file with an MD5 hash of the
main file.  Using RFC 2119 language, what do I do if the hash I get
doesn't match their hash?

For background, there are about 1600 people with passwords to download
the .com file, with a few dozen new passwords issued each month.  I
can tell you what I do with the zone file, but I have no idea what the
other 1599 do.  The downloads are by plain old FTP, since this was set
up a long time ago.

R's,
John

---

From: Michael StJohns <[email-masked]>
Date: Mon, 6 Jan 2020 12:59:49 -0500

> other 1599 do.  The downloads are by plain old FTP, since this was set

Ok - you've described half of this - the download and the validation.   
Let's move on to the use.   E.g. you now have a zone with a good ZONEMD 
- you throw it into what application?   Or you now have a zone with a 
bad (unable to validate) ZONEMD, do you still throw it into the 
application. Does the application check the ZONEMD or did you do that 
manually?   If you throw the zone into the application without 
validation then what?   Do you retry to download it?  How often and how 
long between tries?

If I'm downloading this and all I'm going to do with it is browse the 
text - who cares?  If I'm downloading this and the data is going to end 
up serving infrastructure of some sort then what should I do before I 
come to depend on the data?

Please provide a general rule for automated handling of failed 
validations.  That's all I'm asking.  Of course humans will violate that 
rule - not the point.

Later, Mike

---

From: "John R Levine" <[email-masked]>
Date: 6 Jan 2020 13:48:03 -0500

>> doesn't match their hash? ...

> Ok - you've described half of this - the download and the validation.   Let's 
> move on to the use.   E.g. you now have a zone with a good ZONEMD - you throw 
> it into what application?   Or you now have a zone with a bad (unable to 
> validate) ZONEMD, do you still throw it into the application. Does the 
> application check the ZONEMD or did you do that manually?   If you throw the 
> zone into the application without validation then what?   Do you retry to 
> download it?  How often and how long between tries?

No matter how many times you ask, the answer is the same: it depends on 
the application.

If it's an AXFR to a secondary authoritative server you might do one 
thing, if it's someone collecting stats on TLD zone files, they might do 
something else.

I don't see any benefit to anyone to try to guess how people we don't know 
will use this in applications we don't know about at unknown times in the 
future.  Not only are we not the DNS Police, we're not the Omniscient DNS 
Experts either.

> Please provide a general rule for automated handling of failed validations.

"Do the same thing you do now when a zone is invalid."

Do the same thing you do now when a name is more than 255 octets.

Do the same thing you do now when a RR has an RRTYPE of 252 or 255.

Do the same thing you do now when an SOA isn't long enough to include all 
seven fields, or the SOAs at the beginning and end of an AXFR don't match.

Do the same thing you do now when a TXT character string is longer than 
the RR's RDLENGTH.

Do the same thing you do now when the offset in a compressed name points 
past tne end of the packet, or the pointers create a loop.

I'm sure you can come up with others.

Regards,

---

From: Michael StJohns <[email-masked]>
Date: Mon, 6 Jan 2020 18:03:10 -0500

On 1/6/2020 1:48 PM, John R Levine wrote:
>> Ok - you've described half of this - the download and the 
>> validation.   Let's move on to the use.   E.g. you now have a zone 
>> with a good ZONEMD - you throw it into what application?   Or you now 
>> have a zone with a bad (unable to validate) ZONEMD, do you still 
>> throw it into the application. Does the application check the ZONEMD 
>> or did you do that manually?   If you throw the zone into the 
>> application without validation then what?   Do you retry to download 
>> it?  How often and how long between tries?
>
> No matter how many times you ask, the answer is the same: it depends 
> on the application.

*Sigh* Not exactly.  If you have no automated applications that will use 
this, then it depends on the human and I think that's what you mean by 
"application".  Otherwise, I think you'll find that most automated 
applications will want to (or probably should want to) use the same logic.

> thing, if it's someone collecting stats on TLD zone files, they might 
> do something else.
>
> I don't see any benefit to anyone to try to guess how people we don't 
> know will use this in applications we don't know about at unknown 
> times in the future.  Not only are we not the DNS Police, we're not 
> the Omniscient DNS Experts either.
>
>> validations.

> "Do the same thing you do now when a zone is invalid."

Given that there's no fixed definition of when a "zone" is invalid, I 
don't think I can do the "same thing"?     See below for a screed on 
data protocol vs transport protocol.

The all of these are transport protocol violations and each and every 
one (except possibly the AXFR one?)  of them results in "reject the 
message as being invalidly encoded".     And I'm pretty sure that each 
and every one of these has specific language that says what to do in 
some RFC.

> Do the same thing you do now when an SOA isn't long enough to include 
> all seven fields, or the SOAs at the beginning and end of an AXFR 
> don't match.
>
> Do the same thing you do now when a TXT character string is longer 
> than the RR's RDLENGTH.
>
> Do the same thing you do now when the offset in a compressed name 
> points past tne end of the packet, or the pointers create a loop.
>

DNS is both a transport protocol and a data protocol.  In the beginning, 
the data protocol was pretty simple:   Change a record in the database 
and change the SOA serial at the same time.   The client data protocol 
was mostly "did the name resolve after following the NS records from the 
root?".  The primary to secondary protocol was "did the SOA change, if 
so download the zone again".  There were optimizations here, but that's 
really all there was.   Even then you could find things like lame 
delegations that were violations of the data protocol, but mostly those 
were readily identifiable even from the client side.

Then came DNSSEC.  Which had the effect of turning the zone database 
from a completely incoherent set of data (e.g. records except within 
RRSets were mostly not related to other records and changes to one did 
not require changes to others - exceptions such as CNAME with their 
special handling excepted, and of course SOA serial which provided a 
hint to the secondaries), to a partially coherent database (e.g. 
additions and deletions of names required changes to NSEC/NSEC3, 
additions or changes to an RR within an RRSet required updates to the 
signature records, changes to the DNSKEYs required changes to the DS 
records in the parent zone etc).   DNSSEC still can have data protocol 
errors that can creep in that aren't trivially identified by normal 
query validation failure (e.g. old signatures, names where NSEC says 
there aren't supposed to be names, missing names  or records where NSEC 
says there are supposed to be names), and we still don't actually know 
what to do - automatically - when DNSSEC validation fails.  E.g. what 
action does your home MTA take when DNSSEC validation fails on an 
outbound message server name lookup?   How about for IOT clients phoning 
home?   Yes, the last two may be per-application treatment of validation 
failure, but I don't think ZONEMD falls into the same category.   Note 
that there are a number of other interesting corner cases (E.g. CNAME 
reference from a secured zone to an unknown or untrusted zone generally 
gets reported as secure rather than unknown or untrusted).

Now comes ZONEMD which wants to make a zone database wholly coherent - 
ANY change in the contents of the zone will result in changes to the 
ZONEMD record and to verify it, you MUST download exactly the same data 
as was digested previously.  Unlike changes to the SOA serial, this 
record binds the entire zone to be a very specific set of bits.

AFAICT, ZONEMD verification will output one of "valid" (hash matched), 
"secure valid" (hash matched and ZONEMD chained), "unknown" (no ZONEMD) 
or "invalid" (hash did not match or ZONEMD did not chain when it was 
supposed to), or "???"  (I was told there was an ZONEMD - but its not 
here - where's my ZONEMD?  or Why are there 6 ZONEMD records and why are 
3 duplicates?? or other failures of the data protocol that a well 
meaning human might introduce).

Are you telling me that making a recommendation to a receiver covering, 
even skimpily,  those 4 cases at the front of the RFC for what it should 
do for each of these outputs is out of scope for the document?   OK - 
then I say this is no better than an EXPERIMENTAL RFC.

Later, Mike

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 6 Jan 2020 23:21:24 +0000

Hello Mike, thanks for the feedback.

> On Jan 4, 2020, at 5:14 PM, Michael StJohns <[email-masked]> wrote:
> 
> Hi Tim et al -
> 
> I read through this back a few versions ago and mostly thought it harmless as an experimental RFC.  I'm not sure that it's quite ready for prime time as a Standards track RFC.
> 
> 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 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.

> 2) For each of the use cases, an explanation of how this RRSet actually mitigates or solves the identified problem.  E.g. at least a paragraph each for each the subsections of 1.3. That paragraph should lay out why the receiver of the zone should actually want to do this verification and the cost/benefit of that for the end user.

As one of the coauthors I feel the use cases are pretty self explanatory, but I'm willing to be convinced by others.

> 3)   Section 2 uses SHOULD or MUST related to data content rather than protocol.   That's a problem in that humans are notorious for making mistakes and screwing up the records.   

Thanks, I think I see what you're saying.  Expect changes there.

> Instead - "non-apex ZONEMD RRs MUST be ignored by the receiving client".

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.

> "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".
> and "If there are multiple ZONEMD RRs with distinct DT and Parameters, the zone is acceptable if the       client can verify at least one of those RRs"

I don't understand the use case for this.  IMO multiple ZONEMD RRs with same DT and Parameter, but different digest value is an error and should not be allowed.

> Lower case "recommended" here please.

I don't feel too strongly about it, but can you say why?  By my reading of the key words BCP upper case is appropriate?

> 
> 4) 2.1.3 - The parameter field MUST be set to 0 for SHA384-SIMPLE on creation, and the client MUST NOT accept the RR if this field is not set to zero for SHA384-SIMPLE.

Personally I would be willing to stipulate to that, but not in 2.1.3.  I would rather it go in section 4 (verification).

> 
> 5) 3.1.2 - This is I believe different than how DNSSEC does it?  If it's the same, then this is fine, otherwise this protocol should be calculating the RRSet wire representation the same as DNSSEC does it.

In my experience, duplicates are suppressed either when a zone is loaded or when it is signed.  ZONEMD matches DNSSEC.

Here's how named-checkzone behaves:

$ named-checkzone -i none -o /dev/fd/1 example.com /dev/fd/0
$ORIGIN example.com.
@ 60 SOA a b 1 2 3 4 5
@ 60 NS ns
NS 60 A 192.168.1.1
@ 60 A 127.0.0.1
@ 60 A 127.0.0.1
zone example.com/IN: loaded serial 1
example.com.                                  60 IN SOA         a.example.com. b.example.com. 1 2 3 4 5
example.com.                                  60 IN NS          ns.example.com.
example.com.                                  60 IN A           127.0.0.1
NS.example.com.                               60 IN A           192.168.1.1
OK

And in ldns_dnssec_rrs_add_rr() at https://github.com/NLnetLabs/ldns/blob/develop/dnssec_zone.c#L46 you can see at the end that equal RRs are silently ignored.

> 
> 6) 3.2 - another set of data set MUSTs (the recommended isn't an issue, but should probably be lower       case) that need guidance for the accepting client if the MUST doesn't hold because of human error.

Okay.

> 7) 3.3 - Probably lower case may for DNSSEC.    The rest of this is operational guidance that really doesn't give anything useful for the protocol.  
> 

Okay.

> 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.  

> 
> 9) 3.4.2 - Third bullet.  See above and also, as currently written here this implies you ignore ALL RRs at that owner/class/type/RDATA if there are duplicates.  Rephrase at least.

is this better?

   Include only one instance of duplicate RRs with equal owner, class, type, and RDATA.

> 
> 10) 3.5 - This section needs a bit of re-working.  Generally, what you want to say is that if you have ZONEMD RRs, that they have to be published at the same time as the matching SOA.  

I think you're focusing on the last paragraph of 3.5.  I can attempt to clarify it.

> You also want to probably make a note somewhere that if the SOA and ZONEMD RR do not match on receipt you do ... something?  Not sure what.

Yes, its there, #5 in section 4.

> 
> 11) I really need to write an RFC on "SHOULD considered harmful (if not qualified)".   For section 4, bullet 1 - explain what you mean by SHOULD - e.g. is this a configuration option, or a implementation option.  If a configuration option, in which case might a recipient not want to do this?  If an implementation option, why isn't this a MUST?  Also, if you don't do the DNSSEC thing, identify the next step to be executed (i.e. 4).

How about removing the SHOULD and saying "The verifier first determines ...." ?

> 
> 11.1) Sorry for the numbering - missed step 4 in section 4 - see point 3 and reconcile or remove 3rd and subsequent paras from section 2 to make this section the only normative one.
> 
> 12) 4.1 vs my point 3 above - reconcile, or remove 3rd and subsequent paras from section 2 to make this section the only normative one.
> 
> 13) Missing a section 4.2 which says what you do when a zone doesn't verify.  Otherwise, what's the point?

I'm in alignment with John Levine's responses on this.  It depends.  And if folks are arguing for Experimental then I'd say it doesn't matter.

But if the WG supports Proposed Standard and wants to see such a section 4.2, then with the help of name server implementors I would be willing to add a section describing what name server software should do if the zone is signed with DNSSEC but the ZONEMD doesn't verify.

> 
> 14) Section 6.1, third paragraph is incorrect.  Note that Section 4 step 2 is part of the stuff that's skipped if the zone is provably insecure or if you decide that SHOULD means "I'm lazy and I don't want to do it".  E.g. Section 4 does not "REQUIRE" this because of the preceding  and enclosing "RECOMMENDED".

Okay, will try to fix that.

> 
> 15) Add a section 6.3 to security considerations which describe the downsides of this RR - e.g. for example that it can make a zone more fragile by requiring complete coherence in the zone and that this is a substantial change both to DNSSEC and the original design of DNS.  Or when applied to a large dynamic zone may never be able to calculate a valid digest in time, nor have a recipient accept it.

I will add something to the security considerations.

DW

> 
> 
> 
> I think Experimental is fine.  I'm not sure without a clear text addressing my points 1,2, 13 and 15 that this is useful as a standards track document for general use.  
> 
> 
> 
> Later, Mike
> 
> 
> 
> 
> 
>

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 6 Jan 2020 18:28:12 -0500

Duane

On the zone size point, I would suggest define what you consider to be
'large' and 'very large'.
Today I consider 'large' to be in the 10MM records, but in a year, I would
say 'large' is 30MM records.

Tim

On Mon, Jan 6, 2020 at 6:22 PM Wessels, Duane <dwessels=
[email-masked]> wrote:

> 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.
>
>
> mitigates or solves the identified problem.  E.g. at least a paragraph each
> for each the subsections of 1.3. That paragraph should lay out why the
> receiver of the zone should actually want to do this verification and the
> cost/benefit of that for the end user.
>
> As one of the coauthors I feel the use cases are pretty self explanatory,
> but I'm willing to be convinced by others.
>
>
> 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.
>
>
> >>
> Parameter MUST try to verify each in turn and MUST accept the zone if any
> verify".
> I don't understand the use case for this.  IMO multiple ZONEMD RRs with
> same DT and Parameter, but different digest value is an error and should
> not be allowed.
>
> I don't feel too strongly about it, but can you say why?  By my reading of
> the key words BCP upper case is appropriate?
>
>
> >
> creation, and the client MUST NOT accept the RR if this field is not set to
> zero for SHA384-SIMPLE.
>
> Personally I would be willing to stipulate to that, but not in 2.1.3.  I
> would rather it go in section 4 (verification).
>
> >
> the same, then this is fine, otherwise this protocol should be calculating
> the RRSet wire representation the same as DNSSEC does it.
>
> In my experience, duplicates are suppressed either when a zone is loaded
> or when it is signed.  ZONEMD matches DNSSEC.
>
>
> And in ldns_dnssec_rrs_add_rr() at
> https://github.com/NLnetLabs/ldns/blob/develop/dnssec_zone.c#L46 you can
> see at the end that equal RRs are silently ignored.
>
>
>
>
> >
> but should probably be lower       case) that need guidance for the
> accepting client if the MUST doesn't hold because of human error.
>
> Okay.
>
> this implies you ignore ALL RRs at that owner/class/type/RDATA if there are
> duplicates.  Rephrase at least.
>
> is this better?
>
> want to say is that if you have ZONEMD RRs, that they have to be published
> at the same time as the matching SOA.
>
> > You also want to probably make a note somewhere that if the SOA and
> ZONEMD RR do not match on receipt you do ... something?  Not sure what.
>
> qualified)".   For section 4, bullet 1 - explain what you mean by SHOULD -
> e.g. is this a configuration option, or a implementation option.  If a
> configuration option, in which case might a recipient not want to do this?
> If an implementation option, why isn't this a MUST?  Also, if you don't do
> the DNSSEC thing, identify the next step to be executed (i.e. 4).
>
> How about removing the SHOULD and saying "The verifier first determines
> ....." ?
>
>
> >
> I'm in alignment with John Levine's responses on this.  It depends.  And
> if folks are arguing for Experimental then I'd say it doesn't matter.
>
> But if the WG supports Proposed Standard and wants to see such a section
> 4.2, then with the help of name server implementors I would be willing to
> add a section describing what name server software should do if the zone is
> signed with DNSSEC but the ZONEMD doesn't verify.
>
> >
> 2 is part of the stuff that's skipped if the zone is provably insecure or
> if you decide that SHOULD means "I'm lazy and I don't want to do it".  E.g.
> Section 4 does not "REQUIRE" this because of the preceding  and enclosing
> "RECOMMENDED".
>
> substantial change both to DNSSEC and the original design of DNS.  Or when
> applied to a large dynamic zone may never be able to calculate a valid
> digest in time, nor have a recipient accept it.
>

---

From: "John R Levine" <[email-masked]>
Date: 6 Jan 2020 19:30:22 -0500

> applications will want to (or probably should want to) use the same logic.

I'm sorry, but that continues to make no sense.

>> If it's an AXFR to a secondary authoritative server you might do one thing, 
>> if it's someone collecting stats on TLD zone files, they might do something 
>> else.

I actually have automated software doing both of those.  As I may have 
said once or twice, it depends on the context.

> Given that there's no fixed definition of when a "zone" is invalid, I don't 
> think I can do the "same thing"?     See below for a screed on data protocol 
> vs transport protocol.

Sheesh.  Invalid == contents do not comply with RFC specifications

> Now comes ZONEMD which wants to make a zone database wholly coherent - ANY 
> change in the contents of the zone will result in changes to the ZONEMD 
> record and to verify it, you MUST download exactly the same data as was 
> digested previously.  Unlike changes to the SOA serial, this record binds the 
> entire zone to be a very specific set of bits.

Right.  It's long overdue.  If you want to do incremental updates, that's 
fine, but that's not what this incarnation of ZONEMD binds.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2020 20:22:44 -0500

In article <[email-masked]> 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

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.

>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

---

From: Michael StJohns <[email-masked]>
Date: Mon, 6 Jan 2020 21:15:52 -0500

> Hello Mike, thanks for the feedback.

Hi Duane -

> 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…

As I suggested in one of my messages, giving an idea of how long it 
takes to digest various sizes of zones given commodity hardware would be 
a good start.   Going on and talking about the ratio of that time to the 
typical update frequency of the zone  (e.g. zone digest 5 minutes, 
transfer time of 10 minutes, zone update 24 hours  - ratios of 1:288 and 
1:144 are probably acceptable;   zone digest of 30 minutes, transfer 
time of 2 hours and an update of every 4 hours - ratios of 1:8 and 1:2  
are probably stretching it)

At least give the zone admin and consumer some idea of when doing this 
is just going to be a lost cause.

> As one of the coauthors I feel the use cases are pretty self explanatory, but I'm willing to be convinced by others.

OK.  The point is not to self-approve, but to get a few other 
non-authors to actually see if they can figure out what you're talking 
about here and whether they're ever going to see this use case.    E.g. 
reach out to the consumer side for each of the 4 cases and see if you 
can get some idea of a) would they actually use this, and b) what would 
they do if validation failed or succeeded?

> 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…

Your text "have no meaning in this specification" doesn't actually tell 
me what to do when I receive a non-apex ZONEMD RR. Maybe instead 
"Receivers SHALL NOT attempt to validate non-apex ZONEMD RRs.  All other 
validation rules apply (e.g. inclusion in the HASH using the actual 
value)"....

Assume that someone will screw up and place a ZONEMD RR where it 
shouldn't be.  Figure out what that does to the validation process.   Is 
it included in the hash?  If so, does it get included with the actual 
value of its fields or using the placeholder format?  Or do you check it 
both ways?

If you said forbidden and if included, zone doesn't validate I'd be 
happy too and that would be the simplest.

> I don't understand the use case for this.  IMO multiple ZONEMD RRs with same DT and Parameter, but different digest value is an error and should not be allowed.

Assume the human preparing the zone left the old RR in place and also 
forgot to update the serial number.   So you have two RRs one of which 
will validate and one of which won't.

After consideration, I think I'm actually OK with section 4 bullet 4 so 
you can void this comment.

> I don't feel too strongly about it, but can you say why?  By my reading of the key words BCP upper case is appropriate?

Humans are not protocol elements and MUST/SHOULD can't really apply to 
them.  The inclusion of multiples is choice by a human, rather than a 
decision by a computer.

> Personally I would be willing to stipulate to that, but not in 2.1.3.  I would rather it go in section 4 (verification).

I think that's ok, except that you have "the Parameter field plays no 
role in digest calculation or verification" which I might read as "skip 
the fields when doing the digest calculation". Just delete the last 
sentence I think.

> And in ldns_dnssec_rrs_add_rr() at https://github.com/NLnetLabs/ldns/blob/develop/dnssec_zone.c#L46 you can see at the end that equal RRs are silently ignored.
Can you provide a cite?  Not disagreeing - just curious if its been 
written down in an RFC somewhere.

> I think one legitimate reason would be to avoid ossification, or what I think they call GREASE in the TLS world.

Nope.  Not even close.  The parameter value has meaning only in 
conjunction with the digest type.  In this case, '0' is "no special 
parameters for SHA384-SIMPLE.   For SHA384-SIMPLE, this is an invariant 
and you will not be changing the meaning of SHA384-SIMPLE at a later 
point, or if you do, you're going to be using a different digest number.

This more closely resembles AlgorithmIdentifier - the ASN1 structure 
used in X509 and other PKIX related protocols to define an algorithm type.

>     Include only one instance of duplicate RRs with equal owner, class, type, and RDATA.
"Only one instance of duplicate RRs with equal owner, class, type and 
RDATA SHALL be included"
> Yes, its there, #5 in section 4.

Yup - found it.

> How about removing the SHOULD and saying "The verifier first determines ...." ?

How about just "MUST" instead of SHOULD?

Also, I think its still possible to have zones for which the state is 
"unknown" - e.g. DNSSEC can neither prove nor disprove whether there's a 
requirement for a zone to be signed (e.g. zones subordinate to provably 
unsecure zones and for which the resolver has no trust anchors, but the 
zone itself might actually be signed).   Add guidance for that case please?

> But if the WG supports Proposed Standard and wants to see such a section 4.2, then with the help of name server implementors I would be willing to add a section describing what name server software…

Let's continue to think about this.  If this is a tool with human only 
consumers, then that's fine.  If this is designed to work automatically, 
provide value add for the DNS infrastructure,  and to "do something" if 
validation fails  then guidance is needed for what "do something" looks 
like.

> I will add something to the security considerations.
Thanks - Mike

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2020 21:36:30 -0500

In article <[email-masked]> you write:
>OK.� The point is not to self-approve, but to get a few other 
>about here and whether they're ever going to see this use case.��� E.g. 

Hi again.  I actually do cases 1.3.1, 1.3.2, and 1.3.4 and would use
ZONEMD in all of them, particularly if someone else wrote the verification software.
(I never said I wasn't lazy.)

In my applications I don't think performance would be an issue.

R's,
John

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 7 Jan 2020 14:18:51 +0100

On 1/7/20 3:15 AM, Michael StJohns wrote:
>>>
>>> 1) A recommendation for the maximum size of the zone [...]
>> I am reluctant to add this.  As John said, I think it won't age well.
>> [...]
>
> takes to digest various sizes of zones given commodity hardware would
> be a good start. [...]

Well, if you include particulars in those performance examples: BIND
9.X, zone size Y, CPU Z.  But to me this doesn't seem very suitable for
a static document like RFC standard, and I'd primarily want to see such
examples in docs of the servers, as there they can be kept up to date. 
Still, I see no real harm in putting some performance example(s) into
RFC appendix, and they may just become irrelevant over time.

--Vladimir

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 7 Jan 2020 22:33:52 +0000

> On Jan 6, 2020, at 6:15 PM, Michael StJohns <[email-masked]> wrote:
> 
> As I suggested in one of my messages, giving an idea of how long it takes to digest various sizes of zones given commodity hardware would be a good start.   Going on and talking about the ratio of that time to the typical update frequency of the zone  (e.g. zone digest 5 minutes, transfer time of 10 minutes, zone update 24 hours  - ratios of 1:288 and 1:144 are probably acceptable;   zone digest of 30 minutes, transfer time of 2 hours and an update of every 4 hours - ratios of 1:8 and 1:2  are probably stretching it)

Would text like this address your concern?

7.  Performance Considerations

   This section is provided to make zone publishers aware of the
   performance requirements and implications of including ZONEMD RRs in
   a zone.

7.1.  SHA384-SIMPLE

   As mentioned previously, SHA384-SIMPLE may not be appropriate for use
   in zones that are either large or highly dynamic.  Zone publishers
   should carefully consider the use of ZONEMD in such zones, since it
   might cause consumers of zone data (e.g., secondary name servers) to
   expend resources on digest calculation.  Furthermore, for such use
   cases, it is recommended that ZONEMD only be used when digest
   calculation time is significnatly less than propagation times and
   update intervals.

   The authors' implementation (Section 10.1) includes an option to
   record and report CPU usage of its operation.  The software was used
   to generate digets for more than 800 TLD zones available from [CZDS].
   The table below summarizes the the results for SHA384-SIMPLE, grouped
   by zone size.  The Rate column is the mean amount of time per RR to
   calculate the digest, running on commidity hardware at the time of
   this writing.

                 +---------------------+----------------+
                 |     Zone Size (RRs) | Rate (msec/RR) |
                 +---------------------+----------------+
                 |             10 - 99 |        0.00683 |
                 |           100 - 999 |        0.00551 |
                 |         1000 - 9999 |        0.00505 |
                 |       10000 - 99999 |        0.00602 |
                 |     100000 - 999999 |        0.00845 |
                 |   1000000 - 9999999 |         0.0108 |
                 | 10000000 - 99999999 |         0.0148 |
                 +---------------------+----------------+

   For example, based on the above table, it takes approximately 0.13
   seconds to calculate a SHA384-SIMPLE digest for a zone with 22,000
   RRs, and about 2.5 seconds for a zone with 300,000 RRs.

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 7 Jan 2020 23:01:12 +0000

> Can you provide a cite?  Not disagreeing - just curious if its been written down in an RFC somewhere.
> 

RFC2181 (cited in ZONEMD) says:

   Each DNS Resource Record (RR) has a label, class, type, and data.  It
   is meaningless for two records to ever have label, class, type and
   data all equal - servers should suppress such duplicates if
   encountered.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 7 Jan 2020 23:38:16 +0000

> Your text "have no meaning in this specification" doesn't actually tell me what to do when I receive a non-apex ZONEMD RR. Maybe instead "Receivers SHALL NOT attempt to validate non-apex ZONEMD RRs.  All other validation rules apply (e.g. inclusion in the HASH using the actual value)"....
> 

How about this:

2.1.  Non-apex ZONEMD Records

   This specification utilizes ZONEMD RRs located at the zone apex.
   Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
   specification.  Non-apex ZONEMD RRs MUST NOT be used for
   verification.  Non-apex ZONEMD RRsets are treated like any other
   RRset (which is to say they are included) during digest calculation.

   Unless explicitly stated otherwise, "ZONEMD" always refers to apex
   records throughout this document.

> Assume that someone will screw up and place a ZONEMD RR where it shouldn't be.  Figure out what that does to the validation process.   Is it included in the hash?  If so, does it get included with the actual value of its fields or using the placeholder format?  Or do you check it both ways?

Yes, in fact I myself made this mistake when testing my implementation.  It's why there is a non-apex ZONEMD record in example A.2.

DW

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 07 Jan 2020 21:03:50 -0500

Hi Tim,

> please speak out with your reasons.

I have read this document. I have not attempted to implement the 
described mechanism. With that proviso, I find the text clear and 
well-written. I have no suggestions for improvement. I think the ZONEMD 
mechanism is useful. I think the document is ready for publication.

I don't object to the intended status (standards track). There are 
reports of multiple independent implementations included in the 
document, which seems pleasing and proper.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Jan 2020 02:18:03 +0000

On Jan 7, 2020, at 6:03 PM, Joe Abley <[email-masked]> wrote:
> I don't object to the intended status (standards track). There are reports of multiple independent implementations included in the document, which seems pleasing and proper.

Definitely proper. The calls for making this RFC "experimental" go against the definition for that designation in RFC 2026, Section 4.2.1. 

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Tue, 7 Jan 2020 19:05:30 -0800

On Tue, Jan 7, 2020 at 6:18 PM Paul Hoffman <[email-masked]> wrote:

> reports of multiple independent implementations included in the document,
> which seems pleasing and proper.
>
> Definitely proper. The calls for making this RFC "experimental" go against
> the definition for that designation in RFC 2026, Section 4.2.1.
>

While I think the WG list has been rather quiet on this draft, I think it
is probably best to wait for more responses either way regarding
"experimental" vs "proposed standard".

(ibid) section 4.1 and 4.1.1 does make reference to the maturity level of
standards track documents, and includes the possibility of changes or even
subsequent withdrawal of a standard based on experience.

I concur with Joe, in that the document seems pretty clear, and I support
moving it forward in the standards track.

My $0.02 on the size issue:
I think the onus should be on whoever is publishing a zone with a ZONEMD to
provide guidance on what to do if a failure occurs.
Similarly, publishers should be sensible on whether to include a ZONEMD
based on total size and rate of change.

The onus is on operators to operate their infrastructure with appropriate
levels of caution.
Blindly turning on processing of ZONEMD on zones from random senders might
not be wise.

Brian

---

From: Bob Harold <[email-masked]>
Date: Wed, 8 Jan 2020 09:18:41 -0500

On Tue, Jan 7, 2020 at 10:06 PM Brian Dickson <[email-masked]>
wrote:

>> On Jan 7, 2020, at 6:03 PM, Joe Abley <[email-masked]
>> <jabley@hopcount..ca>> wrote:
>> Definitely proper. The calls for making this RFC "experimental" go
>> against the definition for that designation in RFC 2026, Section 4.2.1.
>>
>
> I think the onus should be on whoever is publishing a zone with a ZONEMD
> to provide guidance on what to do if a failure occurs.

Good point.  Perhaps the RFC should recommend that there be per-zone
options for enabling ZONEMD processing, and perhaps rate limits?

-- 
Bob Harold

---

From: Michael StJohns <[email-masked]>
Date: Wed, 8 Jan 2020 13:58:09 -0500

> In my applications I don't think performance would be an issue.

Hi John -

Could you give me a b) for each of these please?   E.g. How does ZONEMD 
make your life better in each of these and what would happen if you - in 
a future world - were getting ZONEMD data and validation failed?

Later, Mike

---

From: "John R Levine" <[email-masked]>
Date: 8 Jan 2020 14:07:20 -0500

> Could you give me a b) for each of these please?   E.g. How does ZONEMD make 
> your life better in each of these and what would happen if you - in a future 
> world - were getting ZONEMD data and validation failed?

Unless someone else says they find this level of anecdotal detail useful, 
I'll pass.

As I keep telling you, there is nothing new about dealing with invalid 
zones.  This is just another way to find that a zone is invalid, and it is 
hard to imagine how anyone who would use ZONEMD wouldn't already have 
experience dealing with other zone transfer or validation failures.

Regards,

---

From: Michael StJohns <[email-masked]>
Date: Wed, 8 Jan 2020 14:18:45 -0500

Hi Duane -

This is sort of what I meant.  Still trying to get the authors to home 
in a definition for small/static and large/dynamic.   Reading the above 
table, and assuming validation takes a similar time, I'd suggest that 1M 
records @ ~2.3-3 hours is greater than large for your purposes.   Maybe  
10Min  for 100K records is "large"? Assuming that churn is >> 10 minutes.

I'd add "Note that processing power tends to increase over time - 
Moore's law suggest that time to process these data sets will decrease 
by half every 2 years, faster if specialized hardware is used.  
Implementers, publishers and consumers may extrapolate current 
processing times by simple math."  - to deal with the "these numbers are 
stale when published so why publish them" comment .  And - maybe given 
publishing time - as of December 2019 instead of "at the time of writing".

Two things -  Does the above include the time it takes to sort or 
otherwise order the zone in canonical order or are you assuming that the 
database is maintained in a sorted manner?    And what is the average RR 
size?

Thanks for the text.  Mike

ps - what I think a number of other commenters are missing is that this 
is guidance for implementers, zone publishers and zone consumers - not 
just for dns geeks.  For a zone publisher to use it it has to a) be cost 
effective to produce, b) have some value for the zone consumer other 
than "just more data", and c) has to not interfere with their current 
business model.    I actually thought about asking how much 
energy/electricity it would take to produce or verify the ZONEMD RR - 
but decided that would just be cruel.  TANSTAAFL

---

From: Michael StJohns <[email-masked]>
Date: Wed, 8 Jan 2020 14:29:25 -0500

>     data all equal - servers should suppress such duplicates if
And then you have RFC4034 which has

> [RFC2181] specifies that an RRset is not allowed to contain duplicate
>     records (multiple RRs with the same owner name, class, type, and
>     RDATA).  Therefore, if an implementation detects duplicate RRs when
>     putting the RRset in canonical form, it MUST treat this as a protocol
>     error.  If the implementation chooses to handle this protocol error
>     in the spirit of the robustness principle (being liberal in what it
>     accepts), it MUST remove all but one of the duplicate RR(s) for the
>     purposes of calculating the canonical form of the RRset.

Which I think is the better cite.  So basically, the RRSet encoding for 
ZONEMD is the same RRSet encoding for DNSSEC.  Which answers my question.

Thanks - Mike

---

From: Michael StJohns <[email-masked]>
Date: Wed, 8 Jan 2020 14:31:59 -0500

>     records throughout this document.
WFM and quite a bit clearer.
> Yes, in fact I myself made this mistake when testing my implementation.  It's why there is a non-apex ZONEMD record in example A.2.
My point exactly!   I'm not a big fan of ambiguity in protocol 
definitions as you may guess.

Thanks - Mike

---

From: Michael StJohns <[email-masked]>
Date: Wed, 8 Jan 2020 14:38:23 -0500

On 1/7/2020 10:05 PM, Brian Dickson wrote:
> I think the onus should be on whoever is publishing a zone with a 
> ZONEMD to provide guidance on what to do if a failure occurs.
> Similarly, publishers should be sensible on whether to include a 
> ZONEMD based on total size and rate of change.
>
Then there should be some sort of signalling mechanism WITHIN DNS that 
allows a consumer to figure out what to do when the failure occurs - if 
that is going to be a per-zone case.  Perhaps a field in ZONEMD?

What you're suggesting somewhat has the conclusion that this will never 
be useful in general purpose zones, because the consumers of those zones 
would have to have a back channel path to find out the guidance for 
potentially large numbers of zones.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Wed, 8 Jan 2020 14:56:21 -0500

On 1/8/2020 2:07 PM, John R Levine wrote:
>> Could you give me a b) for each of these please?   E.g. How does 
>> ZONEMD make your life better in each of these and what would happen 
>> if you - in a future world - were getting ZONEMD data and validation 
>> failed?
>
> Unless someone else says they find this level of anecdotal detail 
> useful, I'll pass.

Thought so - OK.

Then let me try a "real world" example and give you a few different choices:

I'm running a private copy of the root zone for my organization. I 
(automated) check the SOA every so often, and arrange for a download of 
the zone when it changes.    I (automated) get a copy of the zone data, 
including an ZONEMD RR, everything validates DNSSEC wise, but the ZONEMD 
RR is invalid (hashes don't match). I do:

a) Discard the download, keep retrying until I get a valid ZONEMD RR, 
ignoring any changes in the DNSSEC validated data

b) Install what I've been able to validate DNSSEC wise, and delete 
anything not DNSSEC validated.  E.g. basically ignore the ZONEMD RR and 
install any validated changes.  Log the error. Schedule a download for 
next SOA change.

c) Yell for a human to make a decision.

d) (b) plus turn off ZONEMD RR processing in the future

e) anecdotal author's choice.

> zones.  This is just another way to find that a zone is invalid, and 
> it is hard to imagine how anyone who would use ZONEMD wouldn't already 
> have experience dealing with other zone transfer or validation failures.

And I will note that zones are rarely invalid.  They can have extraneous 
data, or missing targets for things like CNAME.  They can have DNSSEC 
signature types you don't understand.  They can have missing data where 
DNSSEC says they should have data, and they can have data where DNSSEC 
says they shouldn't.   Those don't make the zone IN ITS ENTIRETY 
invalid, unlike what ZONEMD purports to do.

Later, Mike

---

From: "John R Levine" <[email-masked]>
Date: 8 Jan 2020 15:13:07 -0500

On Wed, 8 Jan 2020, Michael StJohns wrote:
> (automated) check the SOA every so often, and arrange for a download of the 
> zone when it changes.    I (automated) get a copy of the zone data, including 
> an ZONEMD RR, everything validates DNSSEC wise, but the ZONEMD RR is invalid 
> (hashes don't match). I do:
> [ various things ]

I know this isn't the answer you want, but it still depends.  One size 
fits all error recovery is rarely possible.  I also realize you're trying 
to tease out a single answer to the question of whether a ZONEMD failure 
is more likely to be a bogus zone or a broken signer, and it still 
depends.

In the rather peculiar case of the root zone, ZONEMD for the first time 
covers the otherwise completely unauthenticated A/AAAA records for the 
root servers since root-servers.net remains unsigned, so it can detect 
tampering that we couldn't detect before.  Since we happen to know that 
significant changes to the root are fairly rare, I'd keep using the old 
version of the root and flag the failure for someone to look at.

In other applications, the risks and consequences are different, so I'd 
probably do something different.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 08 Jan 2020 20:20:36 +0000

[thread fork; subject changed]

i've brought this up several times including in response to the very first 
draft version. i'd like to be sure it's been considered and rejected by the 
dns technical community, rather than merely forgotten.

ZONEMD as drafted is not incremental. so to compute it, the primary server and 
each secondary server must iterate over the entire zone contents. no partial 
products are produced that would make it cheap to simply update the MD when 
some small change to a zone has occurred. in other words ZONEMD is AXFR 
optimized, and roughly ignores the various benefits of IXFR.

some day we will fix this, so that a primary server can update an IXFR 
optimized MD as a result of changes -- either by computing differences between 
an old and new zone, and BIND9 does with "ixfr-from-differences", or by using 
in-band UPDATE. this would look more like a block hash, because each new MD 
would be computed from (previous MD) + (zone change).

i am not asking that we fix this today. what i am asking for is future-
proofing.

can we please not put the ZONEMD RR at the apex, or else, can we please add an 
ALG-ID to its rdata. because some day we're going to ship different kinds of 
MD's, one of which is today's full-zone traversal-required version that 
optimizes for AXFR, and another will be tomorrow's block hash that optimizes 
for IXFR.

so either:

$ORIGIN verisign.com.
@ SOA ...
@ NS ...
@ ZONEMD 1 ... ;; computed by full zone traversal only
@ ZONEMD 2 ... ;; computed by full traversal or incremental block hash

or else:

$ORIGIN verisign.com.
@ SOA ...
@ NS ...
_axfr ZONEMD ...
_ixfr ZONEMD ...

or something else that accomplishes the same goal, which is that today's and 
tomorrow's MD can coexist, and be used opportunistically by dev or ops policy.

vixie

---

From: Brian Dickson <[email-masked]>
Date: Wed, 8 Jan 2020 13:11:07 -0800

> @ ZONEMD 2 ... ;; computed by full traversal or incremental block hash
I like the general format of the second one, as it is easy to tease out
only the current stuff.
It also avoids the issues with internal structure that has been recommended
against.

The specifics of the "_ixfr" label would be an interesting area to think
about in terms of owner name scheme, at some later time.
(E.g. <new-SN>.<old-SN>._ixfr, possibly in their own NSEC zone hierarchies
for easy enumeration, as this is one case where enumeration is good.)

Brian

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 8 Jan 2020 21:22:43 +0000

> On Jan 8, 2020, at 12:20 PM, Paul Vixie <[email-masked]> wrote:
> 

Paul,

The current draft already does this future proofing, although earlier revisions did not. So maybe you missed the change and maybe we haven't done a good job of making this clear.

The ZONEMD Digest Type field encodes both the hash algorithm (SHA384) and the traversal algorithm (SIMPLE).  

A future update can define a new Digest Type such as SHA384-MUMBLE in which the zone is traversed differently but the end result is still a SHA384 hash value.

The Parameter field lets you encode some Digest Type specific parameter information.  Perhaps something like Merkle tree depth, or whatever would be needed for some other traversal algorithm.

DW

---

From: Michael StJohns <[email-masked]>
Date: Wed, 8 Jan 2020 18:55:44 -0500

Hi Duane -

If the above is what you intended, then sections 3 and 4 should be 
labeled "Calculating/Verifying the DIGEST for the SIMPLE scheme", and 
there should be some description elsewhere indicating that later schemes 
will provide replacements for section 3 and 4 at a minimum.

There's also the case that future ZONEMD schemes may need a different 
format for the digest field.   E.g. one approach to dealing with 
incremental changes is to have a NSEC like ZONEMD record which covers 
hashes only across a range of names.

So instead maybe change Digest Type -> Scheme type and Parameter & 
Digest -> Scheme data (which is for this scheme just the digest data).

Later, Mike

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 13 Jan 2020 18:26:12 +0000

> On Jan 8, 2020, at 3:55 PM, Michael StJohns <[email-masked]> wrote:

Mike,

Thank you for these suggestions.  The authors have discussed them.

> If the above is what you intended, then sections 3 and 4 should be labeled "Calculating/Verifying the DIGEST for the SIMPLE scheme", and there should be some description elsewhere indicating that later schemes will provide replacements for section 3 and 4 at a minimum.

This requires fairly large structural changes to the document. It isn't just relabeling the sections because some portions (duplicate RRs, RR ordering) are global, and some are scheme specific -- as it is a Working Group document, we'd like to see support from the WG to make them.

WG, please let us know by the end of the week if you would like us to make these changes.

> There's also the case that future ZONEMD schemes may need a different format for the digest field.   E.g. one approach to dealing with incremental changes is to have a NSEC like ZONEMD record which covers hashes only across a range of names.
> 

We think that the currently documented RR format will solve most use cases - since the digest field is variable length, it already provides a lot of flexibility for future uses, by defining additional Digest Types.  Anything which cannot be solved with this format seems like it would be a sufficiently different protocol that it would deserve a new RRtype and document. 

> So instead maybe change Digest Type -> Scheme type and   Parameter & Digest -> Scheme data (which is for this scheme just the digest data).
> 

Thank you, there are great suggestions, and we think make the document more readable / understandable.

DW

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Jan 2020 14:38:12 -0500

Thought I'd forgotten about this?  :-)

On 1/8/2020 3:13 PM, John R Levine wrote:
>> (automated) check the SOA every so often, and arrange for a download 
>> of the zone when it changes.    I (automated) get a copy of the zone 
>> data, including an ZONEMD RR, everything validates DNSSEC wise, but 
>> the ZONEMD RR is invalid (hashes don't match). I do:
>> [ various things ]
>
> fits all error recovery is rarely possible.  I also realize you're 
> trying to tease out a single answer to the question of whether a 
> ZONEMD failure is more likely to be a bogus zone or a broken signer, 
> and it still depends.

No - I'm trying to tease out what the receiver does without being able 
to determine why the zone didn't validate.  AFAICT you're sticking with 
"there must be a human in the loop because we haven't a clue why it 
didn't validate and we mustn't do anything until we do".   This sounds 
remarkably like the arguments related to DNSSEC and non-DNS dependence 
on validity.

>
> In the rather peculiar case of the root zone, ZONEMD for the first 
> time covers the otherwise completely unauthenticated A/AAAA records 
> for the root servers since root-servers.net remains unsigned, so it 
> can detect tampering that we couldn't detect before. 

Given that I said I'm using this for local publication of the root, 
those glue records are unlikely to be of any interest to me.

In any event, the *right* way to verify those records is to actually try 
and make a connection with them.  That gets you away from "the operation 
was successful (e.g. ZONEMD said these were fine), but the patient died 
(e.g. the addresses didn't actually point to a root instance because 
someone fat fingered the data entry)" problem.

> Since we happen to know that significant changes to the root are 
> fairly rare, I'd keep using the old version of the root and flag the 
> failure for someone to look at.

Would you or would you not add the additional records - e.g. new DS's or 
new names?  Or if the serial was N+1 would you only use the records that 
were there at N?  Keep in mind that DNSSEC says that all of the new 
records validate.   It's just this damn ZONEMD RR that doesn't seem to 
have its act together.

>
> In other applications, the risks and consequences are different, so 
> I'd probably do something different.

Given that - why do you think this is useful for more than a small set 
of DNS geeks?   Yes, info is useful, but either you depend upon it or 
it's just a play thing.  If the former, you have to then start assuming 
other people will depend upon it, which means you need to be serious 
about getting the provisioning right, and at the receiver, discarding 
"bad data".  Something that does not require a human to spend costly man 
hours resolving over and over and over again.

Never mind - I'm not convinced of the general utility of this scheme.  
It feels like DNS bloat and more a solution in search of a problem.   
That said, I appreciate  Duane's willingness to make changes to fix some 
of the more egregious problems.

Later, Mike

---

From: "John R Levine" <[email-masked]>
Date: 13 Jan 2020 14:52:46 -0500

> Thought I'd forgotten about this?  :-)

No such luck, but I'm done.  I don't see any benefit in further argument.

>> I know this isn't the answer you want, but it still depends.  One size fits 
>> all error recovery is rarely possible.  I also realize you're trying to 
>> tease out a single answer to the question of whether a ZONEMD failure is 
>> more likely to be a bogus zone or a broken signer, and it still depends.
>
> No - I'm trying to tease out what the receiver does without being able to 
> determine why the zone didn't validate.  AFAICT you're sticking with "there 
> must be a human in the loop because we haven't a clue why it didn't validate 
> and we mustn't do anything until we do".   This sounds remarkably like the 
> arguments related to DNSSEC and non-DNS dependence on validity.
>
>> 
>> covers the otherwise completely unauthenticated A/AAAA records for the root 
>> servers since root-servers.net remains unsigned, so it can detect tampering 
>> that we couldn't detect before. 
>
> Given that I said I'm using this for local publication of the root, those 
> glue records are unlikely to be of any interest to me.
>
> In any event, the *right* way to verify those records is to actually try and 
> make a connection with them.  That gets you away from "the operation was 
> successful (e.g. ZONEMD said these were fine), but the patient died (e.g. the 
> addresses didn't actually point to a root instance because someone fat 
> fingered the data entry)" problem.
>
>
>> Since we happen to know that significant changes to the root are fairly 
>> rare, I'd keep using the old version of the root and flag the failure for 
>> someone to look at.
>
> Would you or would you not add the additional records - e.g. new DS's or new 
> names?  Or if the serial was N+1 would you only use the records that were 
> there at N?  Keep in mind that DNSSEC says that all of the new records 
> validate.   It's just this damn ZONEMD RR that doesn't seem to have its act 
> together.
>
>
>> 
> Given that - why do you think this is useful for more than a small set of DNS 
> geeks?   Yes, info is useful, but either you depend upon it or it's just a 
> play thing.  If the former, you have to then start assuming other people will 
> depend upon it, which means you need to be serious about getting the 
> provisioning right, and at the receiver, discarding "bad data".  Something 
> that does not require a human to spend costly man hours resolving over and 
> over and over again.
>
> Never mind - I'm not convinced of the general utility of this scheme.  It 
> feels like DNS bloat and more a solution in search of a problem.   That said, 
> I appreciate  Duane's willingness to make changes to fix some of the more 
> egregious problems.
>
> Later, Mike
>
>
>
>
>> 
>> Regards,

Regards,

---

From: Miek Gieben <[email-masked]>
Date: Tue, 14 Jan 2020 07:15:38 +0100

[ Quoting <[email-masked]> in "Re: [DNSOP] Working Group Last Call..." ]
>I'm not convinced of the general utility of this scheme. 
>That said, I appreciate  Duane's willingness to make changes to fix
>some of the more egregious problems.

I like to echo this sentiment; esp considering this draft is heading towards a standards
track.

Also the example given in 1.1 Motivation is a bit weak:

"For example, a name server loading saved zone data upon restart cannot guarantee that the
on-disk data has not been modified.  For these reasons, it is preferable to secure the
data itself."

That looks like an implementation detail for nameservers loading the zone, not something
the IETF should fix.

/Miek

--
Miek Gieben

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 Jan 2020 16:50:13 -0800

<none of my hats; disclaimer: co-author>

Recognizing that this thread has mostly wound down without agreement,
I'll at least add a data point.  I agree that different applications may
behave differently depending on their specific situation and needs.  I
do agree with Mike that automation is needed in the software, but what
to do is not up to the standard but rather the implementation.

I hope to make use of ZONEMD within localroot, which falls into the
scenario you outline:

Michael StJohns <[email-masked]> writes:

> anything not DNSSEC validated.  E.g. basically ignore the ZONEMD RR
> and install any validated changes.  Log the error. Schedule a download
> for next SOA change.
> 

This situation would certainly be annoying, and it would tell me that
there is likely either a problem with the ZONEMD record (as you state)
or the glue records because of some tom-foolery (of any nature).

So, if my localroot/7706 resolver checks the data and finds all the
DNSSEC correct but not the ZONEMD, then I'll probably discard the
result, try again, and if that fails: yell/log, and wait for the next
SOA because that should be safe for the root zone.

I could imagine, however, a different implementation of 7706 doing an
entirely different thing: using the new root zone and it's data when
trying to contact sub-zones, but falling back to the old zone when none
of the "new" glue were working (aka, DoSed by changes).  I could also
see someone else make the opposite change.  I could see some
implementations deciding to stop service (it sure makes users notice
faster).

These are all engineering and deployment decisions, not protocol decisions.
BCPs come later.

-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 Jan 2020 16:52:42 -0800

Michael StJohns <[email-masked]> writes:

> in a definition for small/static and large/dynamic.

Random thought while reading the thread: we could state something very
small and simple rather than trying to approximate the future growth in
computing and DNS data sizes simultaneously.  Instead we could say
something simple like (word smithing needed) "ZONEMD is likely not a
suitable solution for zones where the calculations required to create
the record on the DNS operator's infrastructure takes longer than 1/10th
the average zone update frequency."

-- 
Wes Hardaker
USC/ISI

---

From: Shane Kerr <[email-masked]>
Date: Wed, 15 Jan 2020 09:14:29 +0100

Duane,

> We think that the currently documented RR format will solve most use cases - since the digest field is variable length, it already provides a lot of flexibility for future uses, by defining additio…

Honestly thinking about it more, I'm not even sure we should consider 
supporting an incremental version of zone digests in ZONEMD at all. 
There's no harm in introducing a new type with its own syntax and 
semantics if we tackle that problem in the future.

Some agility is needed to add new hashing algorithms, but beyond that I 
think maybe we should consider ZONEMD perfect in every way and not ever 
needing to be revised. 😉

Cheers,

--
Shane

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Jan 2020 15:05:30 +0000

On Jan 15, 2020, at 12:14 AM, Shane Kerr <[email-masked]> wrote:
> Honestly thinking about it more, I'm not even sure we should consider supporting an incremental version of zone digests in ZONEMD at all. There's no harm in introducing a new type with its own syntax and semantics if we tackle that problem in the future.
> 
> Some agility is needed to add new hashing algorithms, but beyond that I think maybe we should consider ZONEMD perfect in every way and not ever needing to be revised. 😉

Thank you for voicing this, Shane. Given that any incremental digest mechanism will have at least a few significantly different processing rules, I strongly suspect that it would be easier for implementors if there were two different RRtypes. The requests to have both sets of processing rules under one RRtype seems actively dangerous from a security perspective.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Wed, 15 Jan 2020 10:25:11 -0800

On Wed, Jan 15, 2020 at 7:06 AM Paul Hoffman <[email-masked]> wrote:

> >> We think that the currently documented RR format will solve most use
> cases - since the digest field is variable length, it already provides a
> lot of flexibility for future uses, by defining additional Digest Types.
> Anything which cannot be solved with this format seems like it would be a
> sufficiently different protocol that it would deserve a new RRtype and
> document.
> >
> supporting an incremental version of zone digests in ZONEMD at all. There's
> no harm in introducing a new type with its own syntax and semantics if we
> tackle that problem in the future.
> >
> Thank you for voicing this, Shane. Given that any incremental digest
> mechanism will have at least a few significantly different processing
> rules, I strongly suspect that it would be easier for implementors if there
> were two different RRtypes. The requests to have both sets of processing
> rules under one RRtype seems actively dangerous from a security perspective.
>

I don't disagree with the notion of a strong differentiator between ZONEMD
and any other digest, either using RRTYPE or with an underscore-prefix name.

However, there is a Heisenberg problem, which is that any other digest type
needs to be excluded from the ZONEMD calculation (and vice versa).

So, from the future-proofing standpoint, I think one of the two methods
needs to be picked (I think RRTYPE is fine), and a range of types needs to
be reserved for future zone digests.

I'd suggest small range (i.e. more than 1, maybe 4), and include the
reservation in this document with IANA instructions to that effect.

The exclusion of that reserved future-use digest range should be baked into
the ZONEMD calculation itself, so future digests don't require an update to
ZONEMD, and don't result in incompatible deployed digest implementations.
(In other words, future-proof ZONEMD itself.)

Brian

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 16 Jan 2020 00:50:56 +0000

> Honestly thinking about it more, I'm not even sure we should consider supporting an incremental version of zone digests in ZONEMD at all.

I could be easily convinced to take that route.

The first few revisions of the draft were designed that way.  WG discussion back then seemed to focus a lot on the need for having it work with incremental updates.  I felt that it could be accommodated with the addition of an extra field and some future work to hammer out the details. 

>  There's no harm in introducing a new type with its own syntax and semantics if we tackle that problem in the future.

Yes, I think that is a perfectly reasonable approach.  Brian mentioned some potential complications, and I'll respond to his message.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 16 Jan 2020 01:15:37 +0000

> On Jan 15, 2020, at 10:25 AM, Brian Dickson <[email-masked]> wrote:
> 
> However, there is a Heisenberg problem, which is that any other digest type needs to be excluded from the ZONEMD calculation (and vice versa).
> 
> So, from the future-proofing standpoint, I think one of the two methods needs to be picked (I think RRTYPE is fine), and a range of types needs to be reserved for future zone digests.
> 
> I'd suggest small range (i.e. more than 1, maybe 4), and include the reservation in this document with IANA instructions to that effect.
> 
> The exclusion of that reserved future-use digest range should be baked into the ZONEMD calculation itself, so future digests don't require an update to ZONEMD, and don't result in incompatible deployed digest implementations.

Brian,

That could work, but I'm not sure it's required.  You're saying that N types could be defined now (ZONEMD1, ZONEMD2, ...) and that the inclusion/exclusion rules say to just exclude any of these ZONMEDn types when calculating the digests.  

[Note that in the current draft ZONMED excludes only part of itself -- the digest value.  It includes the other fields such as serial.  In other words the exclusion is RR-format-aware.  For the not-yet-defined types you'd probably have to say to exclude the whole RDATA.]

But I think it could be made to work if you define the order of digest calculation.  The newest digest type would always be calculated first.  For example ZONEMD3 would be defined to digest the whole zone except for ZONEMD2 and ZONEMD1 (and their signatures).  ZONEMD2 would include ZONEMD3 in its digest, but not ZONEMD1.  And ZONEMD1 would include all the later types because it didn't know about them when it was written.  I think that would work, but sounds kinda complicated.

Lastly, another, simpler option would be to say that only one digest RR type is allowed in the zone at a time.  Including both ZONEMD1 and ZONEMD2 is an error and cannot be verified.

DW

---

From: Michael StJohns <[email-masked]>
Date: Wed, 15 Jan 2020 20:28:21 -0500

On 1/15/2020 1:25 PM, Brian Dickson wrote:
> I don't disagree with the notion of a strong differentiator between 
> ZONEMD and any other digest, either using RRTYPE or with an 
> underscore-prefix name.
>
> However, there is a Heisenberg problem, which is that any other digest 
> type needs to be excluded from the ZONEMD calculation (and vice versa).
>
> So, from the future-proofing standpoint, I think one of the two 
> methods needs to be picked (I think RRTYPE is fine), and a range of 
> types needs to be reserved for future zone digests.
>
> The exclusion of that reserved future-use digest range should be baked 
> into the ZONEMD calculation itself, so future digests don't require an 
> update to ZONEMD, and don't result in incompatible deployed digest 
> implementations.

*sigh*  I think its a co-existence issue here.  I don't think you should 
have two different (calculation-wise) ZONEMD-like RRSets in the same 
zone for the reasons you've mentioned.  I don't think that reserving RR 
types is the right way of doing things and I'm not sure how you'd write 
the IANA guidance to cover the later assignment of those type numbers.  
It's possible that we can tweak this a bit and get around the problem.

So maybe:

1 byte - Scheme - 1 == SIMPLE

Which has a body of

1 byte - digest - 1 == SHA384, a

followed by N bytes of the appropriate digest length.

And either "Only one Scheme shall be used per zone.  A receiver shall 
consider a zone containing multiple schemes as invalid for the purposes 
of this document".   or "The SIMPLE scheme shall exclude any ZONEMD RR 
of a non-SIMPLE scheme from the digest calculation for the SIMPLE 
scheme" or "ZONEMD digest calculations for any scheme shall only include 
ZONEMD RRs with matching schemes - no placeholder records for non-scheme 
ZONEMD rrs shall be added to the calculation".

I think the last of these three is probably the right approach.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Jan 2020 01:39:46 +0000

On Jan 15, 2020, at 5:28 PM, Michael StJohns <[email-masked]> wrote:
> I think its a co-existence issue here.  I don't think you should have two different (calculation-wise) ZONEMD-like RRSets in the same zone for the reasons you've mentioned.  

That makes good sense. When someone defines an incremental zone hash RRtype, that protocol spec should likely either prohibit ZONEMD RRsets, or state that their interpretation is suppressed. The WG can cross that bridge when we see a reasonably filled-out proposal for INCZOEMD.

> I don't think that reserving RR types is the right way of doing things and I'm not sure how you'd write the IANA guidance to cover the later assignment of those type numbers.

Fully agree.

> followed by N bytes of the appropriate digest length.

Using a different RRtype would be significantly easier and safer due to applications having clearly separate code paths.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Wed, 15 Jan 2020 18:04:59 -0800

Michael StJohns wrote on 2020-01-15 17:28:
> ...  I think its a co-existence issue here.  I don't think you should
+1.

-- 
P Vixie

---

From: Michael StJohns <[email-masked]>
Date: Thu, 16 Jan 2020 11:46:45 -0500

> That makes good sense. When someone defines an incremental zone hash RRtype, that protocol spec should likely either prohibit ZONEMD RRsets, or state that their interpretation is suppressed. The WG…

That doesn't really deal with the problem.  ZONEMD (this document) 
really needs to have similar language, otherwise changing from ZONEMD to 
whatever could cause issues for the receiver. What you want is for both  
(many) to be able to coexist and ignore each other  - IMHO.

> Using a different RRtype would be significantly easier and safer due to applications having clearly separate code paths.

The two different code paths are (pseudocode):

switch (rr.rrtype) {

   case ZONEMD:
           switch (((zonerr)rr).scheme) {
               case SIMPLE:
                    processSimpleZoneMD (rr);
                    break;
               case INCREMENTAL:
                    processIncrementalZoneMD(rr);
                    break;
               default:
                     error();

            }

}

vs

switch (rr.rrtype) {
     case ZONEMD:
         processSimpleZoneMD(rr);
         break;
     case INCZONEMD:
         processIncrementalZoneMD(rr);
         break;

}

Not really sure where you think why one might be safer than another.

Later, Mike

---

From: "John Levine" <[email-masked]>
Date: 17 Jan 2020 22:07:02 -0500

In article <[email-masked]> you write:
>That makes good sense. When someone defines an incremental zone hash RRtype, that protocol spec should likely either prohibit ZONEMD
>RRsets, or state that their interpretation is suppressed. The WG can cross that bridge when we see a reasonably filled-out proposal for INCZOEMD.

That seems to me overdesigned.  If you are able to compute a signature
for the whole zone, put a ZONEMD at the apex.  If you can't, don't.
It includes whatever's in the zone, including INCZONEMD if there
happen to be any.

If you are updating a signed zone with IXFR, either update the ZONEMD
if you are able to recompute a new signature for the zone including
any added or changed INCZONEMD, or delete it in the more likely case
that if you can't.  Why does it have to be more complicated than that?

R's,
John