Hi Duane
On Mon, Oct 29, 2018 at 10:26:42PM +0000, Wessels, Duane wrote:
> Mukund,
>
> Thanks for the comments. I have incorporated most of them. I will follow up
> below on items I did not incorporate.
>
> > On Oct 29, 2018, at 8:55 AM, Mukund Sivaraman <m...@mukund.org> wrote:
> >
> > After a reading, despite what is said in Section 5, I'd like to see such
> > a scheme to be generally useful for larger zones and zones with high
> > rates of updates. There are some kinds of zones in common use which can
> > benefit from better performance. So I recommend working on an
> > incremental scheme now than having multiple types of schemes later.
>
> The feedback I have received regarding this point has been mixed. I have
> some folks saying "make it work with stable zones now, figure out dynamic
> zones later" and others saying "have to support incremental updates now."
>
> The proposal to have a reserved-for-future use field is an attempt to find
> compromise. I personally think incremental updates can be efficiently
> supported with a variable-depth Merkle tree. But I have concerns about
> the complexity / benefit tradeoff. I presented on this at the last DNS-OARC
> meeting (not sure if you had a chance to see it).
>
> This is why the authors propose proceeding with the Reserved field at this
> time.
> If it later turns out we can agree on a way to support incremental updates by
> using this 8-bit field, then that would be great. If not, we can, as you say,
> consume another RR type and the wasted 8-bits stays Reserved indefinitely.
I'll look for the OARC presentation. While this initial scheme is
simple, its usefulness (for zone instances where such a scheme is
desired) to me appears limited outside the root. This is why it seems
better to have a more complicated scheme that scales well.
> >> The root zone [InterNIC] is perhaps the most widely distributed DNS
> >> zone on the Internet, served by 930 separate instances [RootServers]
> >> at the time of this writing.
> >
> > It can be argued, but I think popular RPZ zones have a lot more
> > distribution. More below.
I replied in response to the 930 separate instances mentioned and the
(small) set of servers that run root on loopback, or hijack root
traffic, etc.
Some RPZ zones from proprietary DNS implementation vendors appear to me
in wider use, but I have nothing to cite for it here.
I'd just remove the "most" word, and say "The root zone is a widely
distributed DNS zone..."
> > RPZ seems like a good candidate for end-to-end authentication of data
> > without having to trust the peer a resolver got the data from, esp. for
> > open(unrestricted) policy zones. Some popular RPZ zones are very large,
> > and change very frequently (sooner than a minute). The current memo's
> > performance is inadequate to be used with such zones.
>
> Out of curiosity, are these large RPZ zones signed?
>
> I ask because some people say ZONEMD is worthless without DNSSEC and,
> as far as I know, policy zones don't necessarily need to align with
> the name space.
They are not signed, and you're right that they do not belong in the
DNS, and aren't meant to be QUERY'd. However, they _can_ be signed, and
verified with a local trust anchor. The point I intended to make was
that RPZ can benefit from a message digest where the "master" side
nameserver serving the feed may not be necessarily trusted, but it can
be established that the RPZ feed is authentic. It has importantance for
this application as the contents of the RPZ zones obtained from outside
are used to filter replies.
> >
> >> 2.1.1. The Serial Field
> >
> >> The Serial field is a 32-bit unsigned integer in network order. It
> >> is equal to the serial number from the zone's SOA record ([RFC1035]
> >> section 3.3.13) for which the message digest was generated.
> >
> > Why is this field necessary? Can't the serial number be determined from
> > the SOA's field?
>
> This was a point of discussion in earlier revisions:
>
> FOR DISCUSSION: the serial number is included in order to make DNS
> response messages of type ZONEMD meaningful. Without the serial
> number, a stand-alone ZONEMD digest has no association to any
> particular zone file. If there is agreement that ZONEMD responses
> are not useful, this field could be removed. See also the end of
> Security Considerations.
>
> Based on feedback from that revision, seems like there was consensus to
> keep the Serial field and allow ZONEMD queries/responses.
That is a good reason. Please do retain the description in the
draft. Often when reading RFCs, I see a specification of *what* needs to
be done, but not *why* and the purpose that a field/behavior solves is
mysterious. Sometimes, not knowing the purpose can cause mistakes in
implementation (though not in this case).
> >
> > I had mentioned this in my first reply to an early version of this draft.
> >
> > May I implore that that you avoid other hash types and make SHA-384 as
> > mandatory? So many types are not needed. SHA-512(/384) is a faster hash
> > to calculate on many 64-bit platforms (what will be typically used by
> > this draft's target market) than SHA-256, and its hash construction and
> > size (compared to the rest of the zone) are not very different from
> > SHA-256 to require SHA-256 as well. Speed is good, especially in this
> > simplistic version of this scheme. If you want to include more hash
> > algorithms, pick a different hash construction such as SHA-3.
>
> I was thinking it would be useful to have ZONEMD digest types track DS digest
> types, so that it wouldn't require a new RFC to define a new ZONEMD digest
> type.
> But I'm not sensing much support for this approach.
>
The two are not related, and it's best not to somehow co-relate
them. The choice of function have different requirements which determine
picking a hash function. For example, apart from the fact that crypto
hash functions are needed:
* It would be desired to have short hashes for DS as several of them may
be returned in a delegation response, and delegation responses are a
common answer in the public DNS. Though having a well-performing hash
function would be nice, it is not an important requirement as only the
DNSKEY's key is hashed by it.
* It would be desired to primarily have fast performing hash functions
for ZONEMD as it hashes all the data in the zone. Though having a
short hash is desirable, it is not a big deal even if the hash bloated
up the DNS reply message to the entire 64kB.
> As an implementor, you would be okay with, say SHA384 having value 4 when used
> in as a DS digest type, but value 1 when used as a ZONEMD digest type?
Implementations already deal with hash function identifiers for
different use cases, and it is not a big burden to implement one more,
considering the rest of the ZONEMD implementation.
I feel relating the DS and ZONEMD tables is wrong. You can pick the same
hash function identifier values for now if you choose, but it would be
hard to keep the values in sync, with the separate new registry in 6.2.
> >> For the purposes of calculating the zone digest, RRsets having the
> >> same owner name MUST be numerically ordered by their numeric RR TYPE.
> >
> > in ascending or descending order? (I don't blame you.. RFC 4034 also
> > makes no mention of that except "sorting the names").
>
> Does "... RRsets having the same owner name MUST be processed in numerically
> ascending order by their numeric RR TYPE" work for you?
That works, or very simply add:
"MUST be numerically ordered" + " in ascending order" + " by their numeric RR
TYPE."
>
> >
> >> 3.1.2. Special Considerations for SOA RRs
> >
> >> When AXFR is used to transfer zone data, the first and last records
> >> are always the SOA RR ([RFC5936] Section 2.2). Because of this, zone
> >> files on disk often contain two SOA RRs.
> >
> > Is this fair to say.. the "often" part?
>
> How about "sometimes" instead of often?
Sounds good. I typed a lot of text.. much ado over nothing. :)
> >> Additionally, the ZONEMD record defined in this document includes a
> >> Reserved field. The authors have a particular future use in mind for
> >> this field, namely to support efficient digests in large, dynamic
> >> zones. We intend to conduct future experiments using Merkle trees of
> >> varying depth. The choice of tree depth can be encoded in this
> >> reserved field.
> >
> > Sorry I'm seeing this after writing some comments earlier. This
> > experimental Merkle tree scheme needs to be described more thoroughly to
> > make sense of "depth" to be encoded in the reserved field.
>
> Assuming the document were to move forward with this reserved-for-future-use
> field,
> I'm not sure what would be the appropriate level of detail to put here. I'd
> rather not
> get too caught up in those details yet.
Sorry, I messed up conveying what - the clarification asked was just to
follow why this is an 8-bit Reserved field and not a 16-bit or 32-bit
Reserved field - some justification for what ranges of values are going
to be stored in it.
Mukund
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
