On Nov 1, 2018, at 8:40 AM, Joe Abley <jab...@hopcount.ca> wrote: > > On Nov 1, 2018, at 16:27, Paul Hoffman <paul.hoff...@icann.org> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
