[ Multi-response to four upthread messages. ] -------
On Fri, Mar 03, 2023 at 06:23:11PM -0500, Shumon Huque wrote: > Thanks for your comments. We've posted an updated draft (-01): > > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01 [ Copied from today's dns-operations post on the same general topic. ] A possibly inconvenient question, just to make sure we're not ignoring the obvious sceptical position: * How compelling is compact DoE? The reason to ask is that both the original and now modified protocols involve non-trivial complexity, and would likely require resolvers to respond differently to queries with the DO bit set (pass them the NODATA "truth" along with the NXNAME signal) vs. queries that don't request validated answers (pass them the inferred NXDOMAIN). The savings vs. actual by-the-book NSEC responses appear to be a 2x reduction in the number of signatures to compute (the SOA RRSIG is presumably easily cached) and a 1.5x reduction in the number of signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC). Do the CPU and packet size reductions justify the additional protocol complexity? * There is perhaps another way to ask the question: what is the motivation for compact DoE? Perhaps CPU and packet sizes are a side show and this is all about avoiding zone walking? In that case, might not NSEC3 "1 0 0 -" be good enough? Sure a sufficiently motivated offline dictionary brute-force attacker may be able to discover some names faster with fewer online queries, but is this **really** a concern. How secret do you expect your DNS data to be? A big chunk of many zones ends up for free in certificate transparency logs, or available from various (sometimes paywalled) sources. I am personally not impressed by arguments that DNS names require confidentiality protection stronger than sufficient to deter "casual" zone walking ala plain NSEC. > But the main change is to move from the ENT distinguisher RR type > to an explicit one for NXDOMAIN (with mnemonic NXNAME). The draft fails to explain how queries for the proposed new RRtype are to be handled by authoritative servers and resolvers. ------- On Wed, Mar 15, 2023 at 02:29:56PM +0000, Johan Stenstam wrote: > Our original idea was to propose a different type of DNSKEY, i.e. a > new flag bit in the DNSKEY that would signal “this key is only allowed > to sign negative responses”. We were, however, talked out of that idea > based on the strong wish to get DNSSEC out the door ASAP and therefore > under no circumstances open up the Pandoras Box of further tweaks to > the existing protocol. This runs into a critical problem. A security-critical function of DNSSEC at the public suffix layer (TLDs, ...) is to not be vulnerable to forged denial of existence of DS records for securely delegated domains. **This**, and not avoiding opportunistic DANE TLSA downgrade attacks (also good to have) is the reason that DNSSEC MUST have secure denial of existence. Therefore, signing keys for denial of existence are no less sensitive (at least for zones that sign secure delegations) than signing keys for positive response, and so the various TLD and ccTLD operators need to be just as concerned about handing out negative signing keys. [ And no, I am not about to suggest/endorse NSEC5. ] > And yet, here we are, seventeen years later, still discussing this. So I don't believe that idea can pan out. On Sun, Mar 05, 2023 at 06:20:34PM +0100, Peter Thomassen wrote: > 1.) Maybe it's worth pointing out that zones using compact denial > SHOULD (MUST?) use NSEC, not NSEC3. As others pointed out, "NSEC3 1 0 0 -" could be used, but there's no point. So indeed best to not define a needlessly elaborate variant. > 2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0. This *could* be worth exploring, and has some appeal, but may be too difficult to know to be safe against as yet unseen resolvers that would later come out of the woodwork. Someone would have to be willing to run the experiment at scale. > 3.) Section 2: > > An alternative way to distinguish NXDOMAIN from ENT is to define the > synthetic Resource Record type for ENTs instead, as specified in > [ENT-SENTINEL], and this has already been deployed in the field. This > typically imposes less work on the server since NXDOMAIN responses > are a lot more common than ENTs. Or both. In other words, use two sentinel RRtypes, one to unambiguously signal an ENT, and another to signal NXDOMAIN. This disambiguates the protocol from current practice, though perhaps the ambiguity would not last long if the current operators migrate to the new protocol quickly. > A signed zone at an authoritative server implementing Compact Answers > will never return a response with a response code of NXDOMAIN. > > Is this meant literally, or only for queries with "do" flag? > > For responses to queries without "do" flag, there is no DoE > processing. To preserve the DoE information, the return code fur such > responses should IMO continue to be NXDOMAIN. Correct. ------- On Sun, Mar 12, 2023 at 11:03:58AM +0100, Vladimír Čunát wrote: > On 06/03/2023 03.35, Shumon Huque wrote: > > > I suspect that unilaterally putting NXDOMAIN into the rcode field will > > break a lot of validator code. They are likely to use the rcode to > > advise them on what type of proof to look for in the message body, and > > they won't find a traditional NXDOMAIN proof. > > My understanding of RFCs is that NXDOMAIN or NOERROR are a mandatory > part of what needs to be proven by the records inside. If the proof > doesn't match the RCODE, surely validators should SERVFAIL. I don't > think you can salvage this by a simple new EDNS option; it's the signed > records where you need to prove the result you want. Correct. All the resolvers I've seen reject as bogus mismatches between the RCODE and the enclosed DoE proofs. Since compact denial of existence proofs prove NODATA (to an unmodified validating resolver), the respose RCODE (when DO bit is set) must be NODATA. ------- On Wed, Mar 15, 2023 at 08:48:29AM -0400, Shumon Huque wrote: > So, if a resolver sends EDNS CompactAnswersOK signal to an authority > server, which returns a NODATA+NXNAME proof + RCODE=3 response, then the > resolver would have to intelligently manage that answer in its cache. Adding EDNS0 signals here is much too complex. The DO bit is sufficient. A validating resolver that supports the proposed specification can infer NXDOMAIN from the form of the NSEC RR. If it does not support the proposed specification, then the presented DoE proof is NODATA, and that must be sent. So just always send NODATA (NOERROR) when the DO bit is set in the query. The clients that see the restored NXDOMAIN will be the stub resolvers that don't do validation, and sit behind a local validating forwarder. -- Viktor. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
