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

[Bob Harold <[e-mail]>]

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

> On Nov 1, 2018, at 8:40 AM, Joe Abley <[e-mail]> wrote:
> >
> > On Nov 1, 2018, at 16:27, Paul Hoffman <[e-mail]> 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.
> >
> > 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.
>
> 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