Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Mon, Jul 31, 2023 at 11:58 AM Edward Lewis mailto:edward.le...@icann.org>> wrote: >You've probably stumbled across Cloudflare's differential behavior for DO=0 vs >DO=1 queries. With non-DNSSEC queries it provides a vanilla, unsigned >NXDOMAIN response. With DNSSEC enabled queries, it provides the >Compact Answer NODATA response. Stumbled isn’t the right word - I purposely went looking for it, found it as had I expected. This is what was “feared” in the section in “Protocol Modifications for the DNS Security Extensions” titled “Including NSEC RRs in a Zone“ [a.k.a. RFC 4035, 2.3] - the divergence of the unsecured and secured view of a zone. Backwards compatibility was one of the chief concerns in designing DNSSEC as it was expected that it would take it a very long time to achieve full deployment - and it was anticipated that “islands of security” would emerge before top-down. (I don’t think there are many “islands of security”, especially the way the DNS service economy has emerged this century.) >Your 1st query probably was DO=0. For your 2nd query, I assume the recursive >server that you used sent DO=1 queries upstream by default. Yep. Well, not “by default” - I diddled the DiG run time parameters to make sure I did that… >Yes, this is kind of confusing, and I'm not particularly a fan of this >differential >behavior. “Confusing” situations ought to be avoided. Confusing is a problem in situations when “mean time to repair” matters. My general concern is that although things may “work” in practice today and there’s a desire for expediency, but the way in which this pleases or displeases operations will be a large factor in whether deployment is achieved. As has been the case in other finer points of the extension definitions, the rule against names only having an NSEC (and RRSIG) emerged in the context of developing the signing process. At the time, the prevailing winds would have justified preparing an NSEC resource record set for each name in the zone, including empty non-terminals and possible even those that did not exist (no data and no descendants). I can’t think of a negative impact on a validator verifying that a name had only an NSEC record, but that wasn’t the concern at the time. What wasn’t done was disallowing queries for NSEC, by the time NSEC3 was derived, this was “fixed” (meaning, explicitly barred). Buried in here is the notion that we want to tailor the response to match the query. The only time this is done in base DNS is in answer synthesis (wildcards) and the only field modified there is the owner field. DNSSEC accommodates this (and any decrement to the TTL). We don’t have any precedent in the protocol for modifying the RDATA field based on the query, and DNSSEC was not built anticipating that. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
>Compact DoE, and RFC4470 already appear to violate it for ENT responses. And >it was (arguably) already violated by >pre-computed NSEC3 (5155), where an empty non-terminal name (or rather the >hash of it) does solely own an >NSEC3 record. NSEC3 is different. Because NSEC3 hashes the labels into a flat space, it hides the in-zone structure, which is something a multi-label deep zone [rather uncommon] would need. The impact is that empty non-terminals must by represented in the NSEC3 chain to adequately prove a name does not have records or subordinates (NXDOMAIN). Due to NSEC resource record exposing the full name involved, the resolver can infer where empty, non-terminal names exist in the zone. This is the reason behind the notion that at most two NSEC resource record sets are needed to answer negatively, whereas up to three NSEC3 resource record sets may be needed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Clarifying motivation for Compact DoE
Hi DNSOP, draft-ietf-dnsop-compact-denial-of-existence currently says the following about RFC 4470: The response for a non-existent name requires up to 2 signed NSEC records or up to 3 signed NSEC3 records (and for online signers, the associated cryptographic computation), to prove that (1) the name did not explicitly exist in the zone, and (2) that it could not have been synthesized by a wildcard. However, it seems to me that the wildcard response is extremely cacheable, so in practice online signing with RFC 4470 only requires one signature (even during a cache-busting attack), i.e. the same computational cost as draft-ietf-dnsop-compact-denial-of-existence. This leaves response packet size as the primary advantage over RFC 4470. Is this a fair assessment? If this is correct, then I'm not sure the complexity of solving the ENT problem is worthwhile. Consider the camel [1], and think carefully before defining new mechanisms to solve minor problems. We have many other options, like changing the status to Informational and simply documenting existing practice, or declaring that zones using this strange mechanism must never return NXDOMAIN at all. --Ben Schwartz [1] https://blog.apnic.net/2018/03/29/the-dns-camel/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying motivation for Compact DoE
On Tue, 8 Aug 2023, Ben Schwartz wrote: If this is correct, then I'm not sure the complexity of solving the ENT problem is worthwhile. At $dayjob, I had to add bogus TXT records to our zones because of ENT issues with Amazon Route53, which Amazon knows about and has refused to fix for years. Fixing the ENT problem (somewhere) is useful. It causes issues that are hard to debug for non-DNS (and most DNS) people. This seems more important to me that packet size. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Tue, Aug 8, 2023 at 9:21 AM Edward Lewis wrote: > >Compact DoE, and RFC4470 already appear to violate it for ENT responses. > And it was (arguably) already violated by > > >pre-computed NSEC3 (5155), where an empty non-terminal name (or rather > the hash of it) does solely own an > > >NSEC3 record. > > > > NSEC3 is different. Because NSEC3 hashes the labels into a flat space, it > hides the in-zone structure, which is something a multi-label deep zone > [rather uncommon] would need. The impact is that empty non-terminals must > by represented in the NSEC3 chain to adequately prove a name does not have > records or subordinates (NXDOMAIN). > > > > Due to NSEC resource record exposing the full name involved, the resolver > can infer where empty, non-terminal names exist in the zone. This is the > reason behind the notion that at most two NSEC resource record sets are > needed to answer negatively, whereas up to three NSEC3 resource record sets > may be needed. > > > Thanks Ed. I have in-depth familiarity with all of this :) My original comment about NSEC3 was preceded by "arguably", and I probably should not have brought it up, as Compact DoE doesn't use NSEC3 and none of its subtle properties are relevant. I suggest we go back to focusing on NSEC and the relevant impacts. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Wed, Jul 26, 2023 at 11:05 PM Edward Lewis wrote: > [...] > In some sense, this proposal is establishing a (set of) wildcard(s) > (source[s] of synthesis) that owns just an NSEC record when it applies to > otherwise NXDOMAIN responses. Mulling this over, it becomes apparent that > the next name field in the NSEC record is a problem - wildcards allow for > the inclusion of an owner name pulled from the query (and DNSSEC > accommodates that via the label count) but there is no process for > modifying the RDATA in a synthesized record. The lack of a process for > modifying the RDATA means that "this is something entirely new". > > I think that signing on the fly is a great idea. But when DNSSEC was > defined, and specifically here the NSEC record, it was assumed that DNSSEC > records would be generated on machines air-gapped from the network because > the state of the art in host security was simply poor. This forced the > design to take on an approach of showing the querier "here's what I do > have, you can deduce that your request has no answer (NXDOMAIN)". With > signing on the fly, that approach makes no sense - you should be able to > send a tailored response. > > A tailored response, i.e., "there's no name matching the QNAME", means > there's no need to mention the next name. This would be great - no need to > sort the zone, no need to assist zone walking, etc. The NSEC record is > just not built for that though, it's an entirely ill-fit. > Yes, certainly a different design would have been possible if online signing was a primary use case. But I think NSEC and its minimally covering variant(s) probably do a reasonable job of catering to both pre-computed and online signing models today. I doubt there is an appetite for a larger redesign at this point. In regard to your observations on wildcards, I don't have a direct comment to add -- but I do want to point out that Compact DoE handles wildcards quite differently, and this may not be readily apparent to the casual observer. In this system, a wildcard is not a DNS protocol element that is exposed in the wire protocol, but just an internal response provisioning instruction. Compact DoE implementations pretend that every name that matches a wildcard explicitly existed in the zone and generate an on-the-fly proof for that. This obviates the need to provide an NSEC record in the response that proves that no closer match than the wildcard is possible, and is a simplification enabled by online signing. Some details in: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-compact-denial-of-existence-00#name-responses-for-wildcard-matc Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying motivation for Compact DoE
On Tue, Aug 8, 2023 at 10:45 AM Ben Schwartz wrote: > Hi DNSOP, > > draft-ietf-dnsop-compact-denial-of-existence currently says the following > about RFC 4470: > >The response for a non-existent name requires up to 2 signed NSEC >records or up to 3 signed NSEC3 records (and for online signers, the >associated cryptographic computation), to prove that (1) the name did >not explicitly exist in the zone, and (2) that it could not have been >synthesized by a wildcard. > > However, it seems to me that the wildcard response is extremely cacheable, > so in practice online signing with RFC 4470 only requires one signature > (even during a cache-busting attack), i.e. the same computational cost as > draft-ietf-dnsop-compact-denial-of-existence. This leaves response packet > size as the primary advantage over RFC 4470. Is this a fair assessment? > Yes, the wildcard at the closest encloser name is certainly amenable to pre-computation and caching. Perhaps at a certain scale or under duress, there would be operational issues. The wildcard non-existence proof also requires knowledge of zone structure, which I'm told some DNS implementations have challenges with. Even with only a hash table of names though, this only requires a quick upward search and stripping off a few leading labels, so I'm not convinced this is a practical impediment. There is another case where things can't be pre-computed though. A wildcard "match" in 4470 needs a dynamically generated NSEC covering non-existent labels, which could be randomly posed by an adversary. Compact DoE prevents this by pretending there is an exact match (I'm not sure if that was a design goal though). At any rate, as I've remarked before, I'm not convinced that the optimizations offered in Compact DoE were actually necessary as an operational matter. But I'll leave it to our colleagues at Cloudflare to argue that case. My interest in publishing this spec is (1) to officially record one of the now dominant implementations of DNSSEC amongst the commercial online DNS signers, and (2) to restore more precise NXDOMAIN visibility. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying motivation for Compact DoE
On Tue, Aug 8, 2023 at 11:50 AM Paul Wouters wrote: > On Tue, 8 Aug 2023, Ben Schwartz wrote: > > > If this is correct, then I'm not sure the complexity of solving the ENT > problem is worthwhile. > I'm not sure which "ENT" problem Ben is referring to solving here. The draft proposes ways to precisely identify NXDOMAIN in this system (which involves the ability to distinguish them from ENTs). At $dayjob, I had to add bogus TXT records to our zones because of ENT > issues with Amazon Route53, which Amazon knows about and has refused to > fix for years. > > Fixing the ENT problem (somewhere) is useful. It causes issues that are > hard to debug for non-DNS (and most DNS) people. This seems more > important to me that packet size. > Paul - your ENT issue is a bit different, which is that some implementations incorrectly return NXDOMAIN responses for Empty Non-Terminal names. Amusingly, Amazon's DNSSEC implementation (which is Compact DoE) did in fact address that problem because there are no NXDOMAINs returned ever! :) So, another way you could solve that problem is by signing your Route53 zones! Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Tue, Aug 8, 2023 at 9:13 AM Edward Lewis wrote: > On Mon, Jul 31, 2023 at 11:58 AM Edward Lewis > wrote: > > >You've probably stumbled across Cloudflare's differential behavior for > DO=0 vs > > >DO=1 queries. With non-DNSSEC queries it provides a vanilla, unsigned > > >NXDOMAIN response. With DNSSEC enabled queries, it provides the > > >Compact Answer NODATA response. > > > > Stumbled isn’t the right word - I purposely went looking for it, found it > as had I expected. This is what was “feared” in the section in “Protocol > Modifications for the DNS Security Extensions” titled “Including NSEC RRs > in a Zone“ [a.k.a. RFC 4035, 2.3] - the divergence of the unsecured and > secured view of a zone. > Ah, I stand corrected on "stumbling" :) Note however that Cloudflare quite deliberately implemented this differential behavior (to preserve NXDOMAIN visibility for pre DNSSEC clients I suspect). Some other implementations of Compact DoE return a uniform (NOERROR) RCODE for either case. So, I do not think this is a result of divergence in the contents of the signed vs unsigned zone. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying motivation for Compact DoE
see inline. Shumon Huque wrote on 2023-08-08 12:13: At any rate, as I've remarked before, I'm not convinced that the optimizations offered in Compact DoE were actually necessary as an operational matter. But I'll leave it to our colleagues at Cloudflare to argue that case. My interest in publishing this spec is (1) to officially record one of the now dominant implementations of DNSSEC amongst the commercial online DNS signers, and (2) to restore more precise NXDOMAIN visibility. +1. also: provide coherent implementation guidance for operators who want this. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
