Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies
On Thu, Jul 29, 2021 at 2:29 PM Peter van Dijk wrote: > > > >Empty Non-Terminal Sentinel for Black Lies > > > > Abstract > > > >The Black Lies method of providing compact DNSSEC denial of existence > >proofs has some operational implications. Depending on the specific > >implementation, it may provide no way to reliably distinguish Empty > >Non-Terminal names from names that actually do not exist. This draft > >describes the use of a synthetic DNS resource record type to act as > >an explicit signal for Empty Non-Terminal names and which is conveyed > >in an NSEC type bitmap. > > I have read the draft, and I believe I understand what the draft is doing. > I have also read the Introduction and Motivation section. While it does > contain some motivation, I do not think it contains enough motivation. One > might argue that ENT/NXDOMAIN problems do not exist with these operators, > precisely because they do Black Lies. > > Furthermore, it looks like a trick that could only be relied on with > specific operators (such as, for now, NS1) that have implemented it. There > are plenty of differences between the implementations already. In fact, > when promoting RFC8482, CloudFlare heavily argued how the difference > between NODATA and NXDOMAIN is a very expensive one for them. So > presumably, it would not make sense for them to implement this signal. > Because of that, I wonder if it would not make more sense if the individual > implementers/operators of things that are somewhat similar under the 'Black > Lies'-umbrella document how they signal the difference between ENT and > NXDOMAIN. (It would of course be fine if some of them agree on the signal). > Hi Peter, Yes, Cloudflare is a bit different than the other 2 implementations - they did not exactly follow the spec as described in the expired ID (presumably for the reason you mention, although I don't know enough about their implementation to know why it's hard for them). For any NODATA, including ENT they return a NSEC bitmap that contains every (~ 20) RR type they support except for the queried type. I mention this in the draft. So, they effectively avoid the NXDOMAIN/ENT distinguishability problem that way. I also hope, but want to say that out loud here, that there is no expection > of -resolver- software to handle this signal in any special way. > Confirmed! :) Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies
Hi Shumon, On Tue, 2021-07-27 at 19:34 -0400, Shumon Huque wrote: > Folks, > > While we have the attention of DNSOP folks this week, I'd like to ask for > review of this draft (I meant to send it earlier in time for f2f discussion > on Tuesday, but better late than never). > > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-blacklies-ent-01 > > Excerpt: > >Empty Non-Terminal Sentinel for Black Lies > > Abstract > >The Black Lies method of providing compact DNSSEC denial of existence >proofs has some operational implications. Depending on the specific >implementation, it may provide no way to reliably distinguish Empty >Non-Terminal names from names that actually do not exist. This draft >describes the use of a synthetic DNS resource record type to act as >an explicit signal for Empty Non-Terminal names and which is conveyed >in an NSEC type bitmap. I have read the draft, and I believe I understand what the draft is doing. I have also read the Introduction and Motivation section. While it does contain some motivation, I do not think it contains enough motivation. One might argue that ENT/NXDOMAIN problems do not exist with these operators, precisely because they do Black Lies. Furthermore, it looks like a trick that could only be relied on with specific operators (such as, for now, NS1) that have implemented it. There are plenty of differences between the implementations already. In fact, when promoting RFC8482, CloudFlare heavily argued how the difference between NODATA and NXDOMAIN is a very expensive one for them. So presumably, it would not make sense for them to implement this signal. Because of that, I wonder if it would not make more sense if the individual implementers/operators of things that are somewhat similar under the 'Black Lies'-umbrella document how they signal the difference between ENT and NXDOMAIN. (It would of course be fine if some of them agree on the signal). I also hope, but want to say that out loud here, that there is no expection of -resolver- software to handle this signal in any special way. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies
On Wed, Jul 28, 2021 at 8:18 AM Hollenbeck, Scott wrote: > > > *[SAH] *Something to consider: > https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/ > > > > “The “black lies” term may get called into question. > Hi Scott, I'm aware that this would come up. I'm currently using the term this protocol variation is widely known as. Since it hasn't been technically published yet, we have an opportunity to propose an alternative name. If that happens, I will update the draft. Probably too late for "White Lies" though which has been published. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies
From: DNSOP On Behalf Of Shumon Huque Sent: Tuesday, July 27, 2021 7:35 PM To: dnsop@ietf.org WG Subject: [EXTERNAL] [DNSOP] Empty Non-Terminal sentinel for Black Lies Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Folks, While we have the attention of DNSOP folks this week, I'd like to ask for review of this draft (I meant to send it earlier in time for f2f discussion on Tuesday, but better late than never). https://datatracker.ietf.org/doc/html/draft-huque-dnsop-blacklies-ent-01<https://secure-web.cisco.com/1YTiuVe-DvVNG7ASvMGQwCQ_8P7vWlgGf0Klt0graLQOeSAlwlixroDJUbX3WZFF7Kn7TnRPBnnT3jfDtB2AfUYYX468YiRX2sIyZzlQ3sediqxtTR-XIa4_4vwDY4lHxuasRtJeUrqBhyMoNiLmj6rJ9J7ncpk8MebTabpy5-0YnN5-J-72HOg3al-8ffhW4wx4q0w-xItD3WtYcLR5vo2qQ2b7IBUstbtpTaDK8oHJ3o4RpCDp4Z16ClGXNxCvP/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-huque-dnsop-blacklies-ent-01> Excerpt: Empty Non-Terminal Sentinel for Black Lies Abstract The Black Lies method of providing compact DNSSEC denial of existence proofs has some operational implications. Depending on the specific implementation, it may provide no way to reliably distinguish Empty Non-Terminal names from names that actually do not exist. This draft describes the use of a synthetic DNS resource record type to act as an explicit signal for Empty Non-Terminal names and which is conveyed in an NSEC type bitmap. [SAH] Something to consider: https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/ “The “black lies” term may get called into question. Scott ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies
On Wed, Jul 28, 2021 at 7:42 AM Ralf Weber wrote: > Moin! > > On 28 Jul 2021, at 1:34, Shumon Huque wrote: > > >The Black Lies method of providing compact DNSSEC denial of existence > >proofs has some operational implications. Depending on the specific > >implementation, it may provide no way to reliably distinguish Empty > >Non-Terminal names from names that actually do not exist. This draft > >describes the use of a synthetic DNS resource record type to act as > >an explicit signal for Empty Non-Terminal names and which is conveyed > >in an NSEC type bitmap. > Hmm I may be sleep deprived, but the way I read this is that instead of > giving back NoError/NoData and a standard NSEC responses I now have to > give back an additional record type, so that some client can distinguish > that > as not being NXDomain, which according to the answer it never was? > > Does this mean we would have to change all existing authoritative server > to add this record type to signal an empty non terminal responses? > Hi Ralph, No. This is only for Black Lies implementations (which lie about NXDOMAIN). If you don't do Black Lies, you don't have to do anything. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies
Moin! On 28 Jul 2021, at 1:34, Shumon Huque wrote: >The Black Lies method of providing compact DNSSEC denial of existence >proofs has some operational implications. Depending on the specific >implementation, it may provide no way to reliably distinguish Empty >Non-Terminal names from names that actually do not exist. This draft >describes the use of a synthetic DNS resource record type to act as >an explicit signal for Empty Non-Terminal names and which is conveyed >in an NSEC type bitmap. Hmm I may be sleep deprived, but the way I read this is that instead of giving back NoError/NoData and a standard NSEC responses I now have to give back an additional record type, so that some client can distinguish that as not being NXDomain, which according to the answer it never was? Does this mean we would have to change all existing authoritative server to add this record type to signal an empty non terminal responses? So long -Ralf —-- Ralf Weber ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies
On Tue, Jul 27, 2021 at 8:46 PM Brian Dickson wrote: > On Tue, Jul 27, 2021 at 4:35 PM Shumon Huque wrote: > >> Folks, >> >> While we have the attention of DNSOP folks this week, I'd like to ask for >> review of this draft (I meant to send it earlier in time for f2f discussion >> on Tuesday, but better late than never). >> >> >> https://datatracker.ietf.org/doc/html/draft-huque-dnsop-blacklies-ent-01 >> >> > That's interesting, and I'm definitely in favor of continuing this work. > > A couple of quick questions: > >- Are there distinctions between NSEC and NSEC3, where ENTs and/or >negative proofs result in different response sets? > > I'm not sure I entirely understood your question, but for a specific authenticated denial of existence mechanism (NSEC, NSEC3, NSEC/3 White Lies, Black Lies) the response set should be the same. They will differ between those mechanisms though. In NSEC, an ENT response would contain 1 NSEC record that covers the ENT. In NSEC3, the ENT response would contain 1 NSEC3 record that matches the hash of the ENT. In Blacklies, the ENT response contains 1 NSEC record that matches the ENT. >- Would it make sense to include the synthetic ENT RR as an actual RR >in the unsigned zones for such names (i.e. which, absent this record, would >be ENTs)? > > So that you can easily distinguish ENTs in unsigned zones? I guess that could be of possible use, but I'm not sure how compelling that would be. For me, the goal of this draft is not necessarily to be able to detect ENTs, but to precisely distinguish non-existent names from existing names (of which ENTs are a subset). >- Does it make sense to harmonize the resulting answers across both >"black lies" and pre-signed zones? > - That harmonizing might be advisable and/or necessary in a > multi-signer universe where one provider is statically signing, and the > other is dynamically signing > > Harmonizing the negative answers? Despite their differences, mixing different denial of existence mechanisms in a multi-signer configuration shouldn't cause any issues. We describe why in RFC 8901, Section 5, although mixing online and pre-computed signing will reduce the efficiency of mechanisms like aggressive negative caching. Presumably this would get added to the set of types that must not co-exist > with any other type, and must be singletons. > Yes, but this is really a pseudo type that is only conveyed in a type bitmap, and ENTs by definition have no record types associated with them otherwise - the answer section is always empty. If you query the synthetic type itself, it returns a response without itself in the type bitmap (so it looks like a NODATA). That may seem mildly paradoxical in that it denies its own existence. But we already have a precedent for such behavior in DNSSEC - recall the famed "NSEC3 paradox" :) Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies
On Tue, Jul 27, 2021 at 4:35 PM Shumon Huque wrote: > Folks, > > While we have the attention of DNSOP folks this week, I'd like to ask for > review of this draft (I meant to send it earlier in time for f2f discussion > on Tuesday, but better late than never). > > > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-blacklies-ent-01 > > That's interesting, and I'm definitely in favor of continuing this work. A couple of quick questions: - Are there distinctions between NSEC and NSEC3, where ENTs and/or negative proofs result in different response sets? - Would it make sense to include the synthetic ENT RR as an actual RR in the unsigned zones for such names (i.e. which, absent this record, would be ENTs)? - Does it make sense to harmonize the resulting answers across both "black lies" and pre-signed zones? - That harmonizing might be advisable and/or necessary in a multi-signer universe where one provider is statically signing, and the other is dynamically signing Presumably this would get added to the set of types that must not co-exist with any other type, and must be singletons. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Empty Non-Terminal sentinel for Black Lies
Folks, While we have the attention of DNSOP folks this week, I'd like to ask for review of this draft (I meant to send it earlier in time for f2f discussion on Tuesday, but better late than never). https://datatracker.ietf.org/doc/html/draft-huque-dnsop-blacklies-ent-01 Excerpt: Empty Non-Terminal Sentinel for Black Lies Abstract The Black Lies method of providing compact DNSSEC denial of existence proofs has some operational implications. Depending on the specific implementation, it may provide no way to reliably distinguish Empty Non-Terminal names from names that actually do not exist. This draft describes the use of a synthetic DNS resource record type to act as an explicit signal for Empty Non-Terminal names and which is conveyed in an NSEC type bitmap. [...] Thanks! Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
