Subject: Re: [DNSOP] review: draft-wessels-dns-zone-digest-04.txt

From: Richard Gibson <[email-masked]>
Date: Thu, 1 Nov 2018 09:08:09 -0400

On 10/31/18 19:50, Joe Abley wrote:
>> It sounds wrong to me to say that identical instances of RRs would not be allowed in a zone.
> It's true though, right? It's not meaningful to include more than one resource record with the same (owner,type, class, TTL, RDATA) in the same RRSet, and hence also not meaningful to include such duplicates in a single zone (which is a particular set of RRSets). I don't think RFC 1034 is explicit about this, but it's surely implied. I don't know of any nameserver software that would allow duplicates like that, though, with the possible exception of the SOA. Quite possibly I have just typed more nonsense about this than the world ever needed to see.

RFC 2181 section 5: "It is meaningless for two records to ever have 
label, class, type and data all equal - servers should suppress such 
duplicates if encountered."

And RFC 7719 section 4 affirms the "different data" requirement.

---

From: Joe Abley <[email-masked]>
Date: Thu, 1 Nov 2018 06:13:20 -0700

On Nov 1, 2018, at 09:08, Richard Gibson <[email-masked]>
wrote:

RFC 2181 section 5: "It is meaningless for two records to ever have label,
class, type and data all equal - servers should suppress such duplicates if
encountered."

Excellent.

Joe

---

From: "A. Schulze" <[email-masked]>
Date: Thu, 1 Nov 2018 16:18:22 +0100

Am 01.11.18 um 00:03 schrieb Wessels, Duane:
> I think you might be the first person to argue for supporting multiple ZONEMD algorithms per zone. I actually expected more.

I remember Stephen Farrell saying something like "while designing new protocols, algorithm agility is an important point"
We see the results today in DKIM and DNSSEC. It's really hard to change crypto primitives.

Andreas

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Nov 2018 15:27:20 +0000

> We see the results today in DKIM and DNSSEC. It's really hard to change crypto primitives.

The current ZONEMD draft fully supports algorithm agility. What it doesn't support is multiple hashes *within a single message*. Having seen how easy it is to screw up OpenPGP and S/MIME message processing to handle multiple hashes, I think having one hash per zone is much more likely to work.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Thu, 1 Nov 2018 16:40:14 +0100

> The current ZONEMD draft fully supports algorithm agility. What it doesn't support is multiple hashes *within a single message*. Having seen how easy it is to screw up OpenPGP and S/MIME message pr…

Suppose everybody supports digest algorithm A (e.g. it's the digest type that was mandatory to implement in the original specification). We use that in our ZONEMD RR because we have high confidence that clients will support it.

At some later time digest algorithm B emerges which has some advantages over algorithm A. B is newer and not all software supports it. We would like to use B because its advantages are attractive to us, but we also want all of our clients to be able to use the ZONEMD RRs we publish.

Since B is new we have lower confidence that it is supported by our current clients.

We cannot use both A and B simultaneously on the publication side, since the specification requires us to choose just one.

There is no signalling mechanism that will give us insight into our client population's support of algorithm B, even if we have non-empirical expectations that support will increase over time.

Since we don't want to break things, we cannot use B.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Nov 2018 15:48:51 +0000

> Since we don't want to break things, we cannot use B.

Exactly right. This is precisely the problem that OpenPGP and S/MIME looked at when they created their multisig formats. And the results are incredibly complicated code for validation. It also leads to unanswerable questions like "what if the hash for A is right but the hash for B is wrong".

It's fine to go down the multisig route in this document, and it's fine to punt for a decade or three until a problem is found with SHA256 and SHA384. There are costs for both decisions.

--Paul Hoffman

---

From: Bob Harold <[email-masked]>
Date: Thu, 1 Nov 2018 12:54:34 -0400

On Thu, Nov 1, 2018 at 11:49 AM Paul Hoffman <[email-masked]> wrote:

> >> The current ZONEMD draft fully supports algorithm agility. What it
> doesn't support is multiple hashes *within a single message*. Having seen
> how easy it is to screw up OpenPGP and S/MIME message processing to handle
> multiple hashes, I think having one hash per zone is much more likely to
> work.
> >
> > Suppose everybody supports digest algorithm A (e.g. it's the digest type
> that was mandatory to implement in the original specification). We use that
> in our ZONEMD RR because we have high confidence that clients will support
> it.
> >
> > At some later time digest algorithm B emerges which has some advantages
> over algorithm A. B is newer and not all software supports it. We would
> like to use B because its advantages are attractive to us, but we also want
> all of our clients to be able to use the ZONEMD RRs we publish.
> >
> > We cannot use both A and B simultaneously on the publication side, since
> the specification requires us to choose just one.
> >
> > There is no signalling mechanism that will give us insight into our
> client population's support of algorithm B, even if we have non-empirical
> expectations that support will increase over time.
> >
> Exactly right. This is precisely the problem that OpenPGP and S/MIME
> looked at when they created their multisig formats. And the results are
> incredibly complicated code for validation. It also leads to unanswerable
> questions like "what if the hash for A is right but the hash for B is
> wrong".
>
> It's fine to go down the multisig route in this document, and it's fine to
> punt for a decade or three until a problem is found with SHA256 and SHA384.
> There are costs for both decisions.
>
> --Paul Hoffman_______________________________________________
>
> I don't use DNSSEC or OpenPGP or S/MIME yet, so I have no experience with
this.  My opinion then, for what it is worth...

Allow multiple ZONEMD records with different algorithms or hashes or
whatever.  Expect the receiver to chose the "best" alg and hash that it
supports, and do the verification with that one only.  (Avoid the extra
work for each receiver to check more than one ZONEMD.)  That allows for
adding a new alg or hash.

But we still need some signaling for when everyone understands the new alg
or hash.  An ENDS option could get a signal (what algs and hashes are
supported) back one layer, but we envision a distribution system that could
have multiple independent layers.  Possibly each layer could report back
over time a summary of what it got, when it next pulls from its upstream,
eventually reaching the source.  I don't have a good answer for that.
Perhaps the kinds of hacks we did for the root zone key reporting are
needed.

-- 
Bob Harold

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 02 Nov 2018 23:33:34 -0700

Paul Hoffman <[email-masked]> writes:

> From the earlier list discussion and your presentation at DNS-OARC,
> processing dynamic zones is hard, and you might make different choices
> based on different amounts of dynamicness (dynamicity?). This should
> cause developers concern about implementing ZONEMD now because there
> will be an expectation that they will have to implement the changes in
> the future.

I also look at it in terms of implementation complexity and where in the
code base decisions are made.  EG, if you have different RRTYPEs for
signaling things, then the logic is straight forward:

    if (rrtype == ZONEMD) {
       do_ZONEMD_stuff();
    } else if (rrtype == ZONEMDMERKLE) {
       do_fancy_new_hashtree_stuff();
    } ...

On the other hand, with a reserved field we end up here:

    if (rrtype == ZONEMD) {
       do_ZONEMD_stuff();
    } ...

    do_ZONEMD_stuff() {
        if (reserved_field != 0) {
            do_fancy_new_hashtree_stuff();
        } else {
            do_ZONEMD_stuff();
        }
    }

Now, if do_ZONEMD_stuff() and do_fancy_new_hashtree_stuff() are likely
to be sufficiently different in implementation (and I suspect they will
be), then the first code above with two RRTYPEs is likely to be
cleaner.  The only advantage gained in the second type is if you can put
the brunt of the code for both do_fancy_new_hashtree_stuff() and
do_ZONEMD_stuff() pretty much inline because there is sufficient
overlap.

It's hard to predict what the best route is advance without knowing now
how much the resulting double implementation will overlap.

Personally (authorship hat off and thus collector of consensus hat off),
I think we should use a second RRTYPE for the future as it's easier to
make implementations more module and remove earlier implementations when
that specification is no longer used because hashtrees are so cool that
nothing else is ever needed.

-- 
Wes Hardaker
USC/ISI

---

From: "Wessels, Duane" <[email-masked]>
Date: Sun, 4 Nov 2018 04:05:44 +0000

> On Nov 3, 2018, at 1:33 PM, Wes Hardaker <[email-masked]> wrote:
> 

So there is an implementation of ZONEMD, and even an implementation of "fancy hashtree stuff".  You can find it at https://github.com/verisign/ldns-zone-digest

One of the reasons I think the variable-depth hash tree is attractive is because when depth = 0 then it simplifies exactly to the case as though there is no fancy hashtree.  

In my proof-of-concept implementation, most of the added complexity from fancy hashtree stuff comes in the form of how the zone data is stored.  For example:

    #if !ZONEMD_INCREMENTAL
    ldns_rr_list *the_rrlist = 0;
    #endif

    #if ZONEMD_INCREMENTAL
    typedef struct _zonemd_tree {
        unsigned int depth;
        unsigned int branch;    // only for debugging?
        ldns_rr_list *rrlist;
        struct _zonemd_tree *parent;
        struct _zonemd_tree **kids;
        unsigned char digest[EVP_MAX_MD_SIZE];
        bool dirty;
    } zonemd_tree;
    #endif

But the actual digest calculation is not that much more complex for fancy hashtree sutff, IMO.  The only difference is what you feed as input to the hash function.  At the non-leaf nodes the input is hash values of the child nodes.  At the leaf nodes the input is the RRs wire format data.

DW