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:
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
