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 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
On 1 Aug 2018, at 9:31, Paul Wouters wrote: I strongly prefer a regular rrtype over any kind of special processing or complicating dnssec further. Agree. If axfr signatures aren’t enough because people envision non-dns zonefile transports, do a single ZONEMD, which signs the whole thing or only all records without RRSIG. My proposed NONAUTH-RRSIG is not exclusively for zonefile transport. It would be useful for normal resolver-authoritative queries as well. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
I strongly prefer a regular rrtype over any kind of special processing or complicating dnssec further. If axfr signatures aren’t enough because people envision non-dns zonefile transports, do a single ZONEMD, which signs the whole thing or only all records without RRSIG. Paul Sent from my phone > On Aug 1, 2018, at 09:14, Paul Hoffman 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
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
Re: [DNSOP] zonemd/xhash versus nothing new
Petr Špaček wrote: > > One problem I can see is that these additional RRSIGs effectively > prevent modification of data but not removal of glue (or NS in out-out > intervals) ... I was kind of assuming that the NSEC chain would include the glue - obviously delegations and glue in opt-out intervals are not protected at all. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: South or southwest 4 or 5, occasionally 6 at first in Cromarty and Forth, then becoming variable 3 at times. Slight throughout in Tyne and Dogger, but elsewhere slight or moderate. Fair then rain at times. Good, occasionally moderate.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
On 31.7.2018 16:58, Tony Finch wrote: > Petr Špaček wrote: >> On 30.7.2018 15:32, Tony Finch wrote: >>> >>> I keep thinking it might make sense to sign non-authoritative delegation >>> records, though it's really hard to see how we could get there from here. >>> For instance, there isn't a flags field in RRSIG so you can't explicitly >>> mark an RRset as being non-authoritative. >> >> It is! RRSIG has signer name field which points to node with particular >> DNSKEY. If signer name is shorter than zone apex name the signature was >> created by someone up the tree. > > It would be nice if that is enough :-) For NS records the RRSIG signer > will either be the same as the owner (apex RRset) or shorter (delegation > RRset). For glue it's not so clear-cut if you don't have any > apex/delegation records to hand. But maybe the other context is enough - > the section that the records appear in, the RFC 2181 priority order. > > The other question I can't answer is whether existing validators will be > discombobulated by an RRSIG of unknown algorithm on a delegation NS > RRset... Well, there is a posibility not to send out these RRSIGs for normal queries. Auth server has to have special code to handle delegations anyway so I can imagine that these parent-side RRSIGs are present only in zone transfer. One problem I can see is that these additional RRSIGs effectively prevent modification of data but not removal of glue (or NS in out-out intervals) ... -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
Petr Špaček wrote: > On 30.7.2018 15:32, Tony Finch wrote: > > > > I keep thinking it might make sense to sign non-authoritative delegation > > records, though it's really hard to see how we could get there from here. > > For instance, there isn't a flags field in RRSIG so you can't explicitly > > mark an RRset as being non-authoritative. > > It is! RRSIG has signer name field which points to node with particular > DNSKEY. If signer name is shorter than zone apex name the signature was > created by someone up the tree. It would be nice if that is enough :-) For NS records the RRSIG signer will either be the same as the owner (apex RRset) or shorter (delegation RRset). For glue it's not so clear-cut if you don't have any apex/delegation records to hand. But maybe the other context is enough - the section that the records appear in, the RFC 2181 priority order. The other question I can't answer is whether existing validators will be discombobulated by an RRSIG of unknown algorithm on a delegation NS RRset... Tony. -- f.anthony.n.finchhttp://dotat.at/ an equitable and peaceful international order___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
On 30.7.2018 15:32, Tony Finch wrote: > Paul Wouters wrote: >> >> We are looking at a way to distribute the root zone, presumably to >> make the root servers less mission critical and for enhanced >> privacy and reduced NXDOMAIN queries. > > RFC 8198 with qname minimization give you the latter two. > >> We are depening on DNSSEC for integrity of the data, which just misses >> glue/NS verification. > > I keep thinking it might make sense to sign non-authoritative delegation > records, though it's really hard to see how we could get there from here. > For instance, there isn't a flags field in RRSIG so you can't explicitly > mark an RRset as being non-authoritative. It is! RRSIG has signer name field which points to node with particular DNSKEY. If signer name is shorter than zone apex name the signature was created by someone up the tree. I think this is an interesting idea worth exploring. Petr Špaček @ CZ.NIC > >> It seems the way to fix this would be to have well known recursive servers >> (8.8.8.8, 1.1.1.1, 4.4.4.4, level3, opendns, etc) also offer the root >> zone for AXFR. > > This just makes the surveillance capitalists part of your mission critical > problem area, which isn't obviously an improvement. > > Tony. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
On Jul 30, 2018, at 5:03 PM, Wes Hardaker wrote: >> I think the use for non-root zones is quite a different use case, I don’t. >> so if >> I ignore that, we are looking at specifically the root zone only. > > Please don't ignore that. We really do ourselves a disservice when we > design a solution that only works for singular or minimal instances. > This is beneficial to more than just the root zone. +1 I don’t think the benefits of mirroring a zone into a resolver is limited to the root. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
Paul Wouters writes: > What I see is that: > > We are looking at a way to distribute the root zone > maybe this is also useful for non-root zones, so the method was sort > of made to apply generically. > I think the use for non-root zones is quite a different use case, so if > I ignore that, we are looking at specifically the root zone only. Please don't ignore that. We really do ourselves a disservice when we design a solution that only works for singular or minimal instances. This is beneficial to more than just the root zone. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
Paul Wouters wrote: > > We are looking at a way to distribute the root zone, presumably to > make the root servers less mission critical and for enhanced > privacy and reduced NXDOMAIN queries. RFC 8198 with qname minimization give you the latter two. > We are depening on DNSSEC for integrity of the data, which just misses > glue/NS verification. I keep thinking it might make sense to sign non-authoritative delegation records, though it's really hard to see how we could get there from here. For instance, there isn't a flags field in RRSIG so you can't explicitly mark an RRset as being non-authoritative. > It seems the way to fix this would be to have well known recursive servers > (8.8.8.8, 1.1.1.1, 4.4.4.4, level3, opendns, etc) also offer the root > zone for AXFR. This just makes the surveillance capitalists part of your mission critical problem area, which isn't obviously an improvement. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher, German Bight: Southerly or southeasterly 4 or 5, occasionally 6 in west Fisher. Slight or moderate. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
On Fri, Jul 27, 2018 at 06:17:37PM -0400, Paul Wouters wrote: > we can do AXFR but that would keep the root servers mission critical. Also, the only currently practical channel security for AXFR is TSIG and it can't scale to hundreds of thousands of clients. Speaking as an implementer, I like AXFR from the traditional root servers as a method of distribution (despite the regrettable fact that half of them don't support AXFR; I wish they would). Reducing the root servers' central role isn't a major concern for me, and I don't think daily zone transfers from resolvers will overly tax them. The code's long-since implemented and mature and using it doesn't introduce a lot of new moving parts. However, the inability to verify a the correctness and completeness of a zone transfer (including the gluey bits) with an in-band signature *is* a problem. ZONEMD/XHASH solves it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] zonemd/xhash versus nothing new
On Fri, 27 Jul 2018, Warren Kumari wrote: This can, but does not have, to be built into the nameserver itself. Those are just more arguments to not have a DNS checksum/sig option. What I see is that: We are looking at a way to distribute the root zone, presumably to make the root servers less mission critical and for enhanced privacy and reduced NXDOMAIN queries. We are depening on DNSSEC for integrity of the data, which just misses glue/NS verification. we can do AXFR but that would keep the root servers mission critical. glue/NS verification isn't needed normally, because we would just need a single working entry to pull the new root zone from one of the root servers - but then we depend again on the root servers as critical infrastructure which is something we seem to want to try and avoid. maybe this is also useful for non-root zones, so the method was sort of made to apply generically. I think the use for non-root zones is quite a different use case, so if I ignore that, we are looking at specifically the root zone only. What is the pain of getting a root zone file from an unknown/untrusted source ? - transport seurity isn't enough (so no (D)TLS) - detached sigs like pgp too annoying/hard? (two files instead of one, or the one file needs preprocessing before giving it to DNS tools) - we have to validate it with the known key (so some tooling needed) - glue/ns could be filtered (either a ddos, or a privacy concern?) - we cannot depend on finding 1 working root server and then AXFR it to confirm, assuming that would be too much load on the existing root servers (although load of junk queries would decrease if this is deployed) It seems the way to fix this would be to have well known recursive servers (8.8.8.8, 1.1.1.1, 4.4.4.4, level3, opendns, etc) also offer the root zone for AXFR. If you get something that does not work, fall back to standard recursive root zone queries based on the buildin hints file. We could also do some /.well-known/root.zone URI to allow for other https/tls servers for serving the zone without being a public resolver, eg for enterprise or isp network use only? Maybe a dhcp option to point to the location? Additionally, these servers could allow downloads of the root zone via HTTPS/TLS/etc for those tools that want to write a root zone file to disk for re-use or for preloading a resolver cache on startup ? In all of this, I don't see much use in protecting the root zone with either ZONEMD or XHASH. If the NS/glue is mangled to the point of being unusable to refresh the root zone, drop the garbage and do traditional DNS querying from the preloaded hints or previous copy of the root zone. If ZONEMD or XHASH was a regular record with no special handling, maybe it could be worth it, but it is a very a-typical RRTYPE and I think there isn't a very strong case for adding it to the DNS system. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
