Re: [DNSOP] zonemd/xhash versus nothing new

Hi Paul,

I agree that it would be foolish to change 4034/4035 without understanding the implications of doing so (e.g. breaking validators).

However, it's possible that it would be a fairly minor semantic change, e.g. if signing records with an owner name below a zone cut was optional and if validator code paths were not much affected (they could either validate when they saw the RRSIG or ignore the RRSIG, either way it's possible that things would not break).

Before the idea of using RRSIGs to sign records that are currently specified not to be signed is thrown away, is it perhaps worth exploring it a little more deeply?

Joe

> On Aug 1, 2018, at 12:14, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
> Maybe changing RFC 4034 and RFC 4035 to have RRSIGs over non-authoritative data is not the right way to go. It could break some current validators, and it would be hard to let zones sign some but not all of the non-authoritative data. (For example, I could imagine a zone owner wanting to sign the child NS records but not the glue records.)
> 
> Instead, of the WG wants this functionality, it might be cleaner to create a new record that acts like RRSIG but is used only on non-authoritative data. Think of it as NONAUTH-RRSIG. We would need to define the new RRtype (with a lot of pointers to RFC 4034), how it is used to sign (with a lot of pointers to RFC 4035), how authoritative servers would include those records in responses, and how validators would handle the records (this would probably be the trickiest part).
> 
> This would lead to a cleaner upgrade path both for authoritative servers and resolvers, and thus maybe make it more palatable to the current DNSSEC-using population.
> 
> --Paul Hoffman
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop