Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
On Thu, Mar 2, 2023 at 2:10 AM Paul Vixie wrote: > > > > Address lookup functions typically invoked by applications won't see > > a practical impact from this indistinguishability. For a non- > > existent name, the getaddrinfo() function for example will return a > > value of EAI_NODATA rather than EAI_NONAME. But either way the > > effect on the caller is the same: it will obtain a response with a > > non-zero return value and no available addresses. > > that's just not true, no matter how it's worded. > > if i get NODATA i might try other record types (for example, after > A, A after , or both and A after MX). > > if i get NXDOMAIN, i won't. > That's a fair point. It may cause calling applications to issue additional queries, although I guess the final state will be the same. > there's also a huge impact on operational security. > > indistinguishability would a huge problem. > > please outlaw it. > I don't think this mechanism can be outlawed since it is already so widely deployed in the field. What we can do is to make it easier to make the distinction, which is what we are attempting to do with the distinguishability (pseudo) type in the type bitmap. As I mentioned earlier, we have some proposed tweaks to that mechanism which I'll start a new thread about. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
On 3/2/23 00:14, Joe Abley wrote: We are not talking about lies. Referring to these kinds of negative responses as lies is confusing and unhelpful. They are signed responses, and the point of signing them is that they are verifiably true. I think "lies" refers to an assumption that a single NSEC makes a maximal assertion about what does not exist and that either side of that expanse of empty sand lies a soothing oasis of existence. However theprotocol doesn't require that to be the case. A single NSEC can cover a single grain of sand, and the mystery of the desert can remain substantially intact. As always, the truth lies with you. ;-) (In other words, ack.) ~Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
On Thu, Mar 2, 2023 at 1:42 AM Florian Obser wrote: > > I might not be caffeinated enough yet, but I think the next domain name > in section 5 should be \000.ent1.example.net: > > ent1.example.net. 3600 IN NSEC \000.ent1.example.net. RRSIG > NSEC ENT > I'm the one who wasn't caffeinated. Good catch. Will fix in next version. > In section 6, calling getaddrinfo() return values exit codes is a bit > odd, maybe this will do? > Yes, we can say return values. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
Florian Obser wrote on 2023-03-01 22:42: I might not be caffeinated enough yet, but I think the next domain name in section 5 should be \000.ent1.example.net: ent1.example.net. 3600 IN NSEC \000.ent1.example.net. RRSIG NSEC ENT In section 6, calling getaddrinfo() return values exit codes is a bit odd, maybe this will do? Address lookup functions typically invoked by applications won't see a practical impact from this indistinguishability. For a non- existent name, the getaddrinfo() function for example will return a value of EAI_NODATA rather than EAI_NONAME. But either way the effect on the caller is the same: it will obtain a response with a non-zero return value and no available addresses. that's just not true, no matter how it's worded. if i get NODATA i might try other record types (for example, after A, A after , or both and A after MX). if i get NXDOMAIN, i won't. there's also a huge impact on operational security. indistinguishability would a huge problem. please outlaw it. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
I might not be caffeinated enough yet, but I think the next domain name in section 5 should be \000.ent1.example.net: ent1.example.net. 3600 IN NSEC \000.ent1.example.net. RRSIG NSEC ENT In section 6, calling getaddrinfo() return values exit codes is a bit odd, maybe this will do? Address lookup functions typically invoked by applications won't see a practical impact from this indistinguishability. For a non- existent name, the getaddrinfo() function for example will return a value of EAI_NODATA rather than EAI_NONAME. But either way the effect on the caller is the same: it will obtain a response with a non-zero return value and no available addresses. -- In my defence, I have been left unsupervised. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
gih> for what its worth I would like to chime in and support George's gih> view. The technique is NOT a lie per se. I'll "me too" this with George and Geoff. Figuring out a more efficient way to do what is ultimately wanted (crypographically provable denial of existence) that works better than the original conception is a good thing. And using "lie" was cute but George is right here too; clarity/consistency to not confuse the world is more useful than yet another "in" joke in DNS. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
Hi George, On Wed, Mar 1, 2023 at 17:40, George Michaelson wrote: > My opposition is philosophical and practical. > > the philosophical part, is that this is a SIGNED ASSERTION by the zone > authority. I don't think anything the zone authority says under a > signature should be called a lie, because the basis of verification is > that its exactly what was intended to be said about the state of the > zone. I agree with this. We are talking about an assertion by those responsible for the zone contents about things that do not exist. There are many different truthful assertions of that kind that can be made. The interesting thing about this particular choice is that it's a minimal assertion. We are not talking about lies. Referring to these kinds of negative responses as lies is confusing and unhelpful. They are signed responses, and the point of signing them is that they are verifiably true. I think "lies" refers to an assumption that a single NSEC makes a maximal assertion about what does not exist and that either side of that expanse of empty sand lies a soothing oasis of existence. However the protocol doesn't require that to be the case. A single NSEC can cover a single grain of sand, and the mystery of the desert can remain substantially intact. Joe___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
for what its worth I would like to chime in and support George’s view. The technique is NOT a lie per se. It's a stretch (well its the opposite of “stretch” - its a “compression”) of the intended contents of the denial of existence response, but it is not a lie as I see it. I would be far more comfortable as well with Shumon’s “Compact Denial of Existence” as a more accurate description of the technique. regards, Geoff > On 2 Mar 2023, at 9:40 am, George Michaelson wrote: > > My opposition is philosophical and practical. > > the philosophical part, is that this is a SIGNED ASSERTION by the zone > authority. I don't think anything the zone authority says under a > signature should be called a lie, because the basis of verification is > that its exactly what was intended to be said about the state of the > zone. > > its incoherent, its potentially confusing, it needs to be understood, > sure. but I don't see this as a lie. > > the practical is that I think the IETF/OPS tendency to enjoy "puns" > causes huge confusion outside the cognoscenti. The re-use of the word > "peer" for instance has caused significant dismay to people in policy > or finance space who don't understand that a BGP peer does not mean > necessarily a peering zero-cost sum arrangement at layer 8 and 9 > (money). -If we use "lie" this freely, then when we want to > distinguish these signed lies from the intermediary altering payload > on-the-fly we're going to have a problem of comprehension. > > Having said that, I think I feel like a bit of a party pooper. What in > Australia would be called a "wowser" > > It's not a big deal btw. I'm not going to go to the AD and complain > about it or make a fuss at WGLC. I just think.. its the kind of > language which may not be helpful in the longer term. > > cheers > > George > > On Thu, Mar 2, 2023 at 7:33 AM Shumon Huque wrote: >> >> Hi folks, >> >> We've posted a new draft describing the former "Black Lies" mechanism >> for authenticated denial, now renamed as "Compact Lies". >> >>https://datatracker.ietf.org/doc/draft-huque-dnsop-compact-lies/ >> >> We are hoping to discuss it here and at IETF116, and see if there is >> interest in adopting the work and publishing it. We feel that it deserves a >> stable published specification since it is now one of the dominant forms >> of authenticated denial deployed amongst the commercial online signers >> today (notably Cloudflare, NS1, and Amazon Route53). >> >> The draft includes the NXDOMAIN/Empty Non-Terminal distinguisher >> mechanism I described at IETF 111 ( >> https://datatracker.ietf.org/meeting/111/materials/slides-111-dnsop-sessb-black-lies-ent-sentinel-01 >> ) and currently implemented >> by NS1. >> >> Christian and I are currently discussing some tweaks to that mechanism >> which we will broach in a separate email thread shortly. This thread can be >> used for general comments on the topic of the draft. >> >> George Michaelson, in private email to me, has expressed the view >> that we shouldn't be calling these mechanisms "Lies" any more (I'm >> sure he will elaborate if he is inclined). I'm personally okay with that, >> and if >> there is agreement, we could just call this Compact Denial of Existence, >> and discard the "Lies" meme. >> >> Shumon >> > > ___ > 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] New draft: Compact Lies/Denial of Existence in DNSSEC
My opposition is philosophical and practical. the philosophical part, is that this is a SIGNED ASSERTION by the zone authority. I don't think anything the zone authority says under a signature should be called a lie, because the basis of verification is that its exactly what was intended to be said about the state of the zone. its incoherent, its potentially confusing, it needs to be understood, sure. but I don't see this as a lie. the practical is that I think the IETF/OPS tendency to enjoy "puns" causes huge confusion outside the cognoscenti. The re-use of the word "peer" for instance has caused significant dismay to people in policy or finance space who don't understand that a BGP peer does not mean necessarily a peering zero-cost sum arrangement at layer 8 and 9 (money). -If we use "lie" this freely, then when we want to distinguish these signed lies from the intermediary altering payload on-the-fly we're going to have a problem of comprehension. Having said that, I think I feel like a bit of a party pooper. What in Australia would be called a "wowser" It's not a big deal btw. I'm not going to go to the AD and complain about it or make a fuss at WGLC. I just think.. its the kind of language which may not be helpful in the longer term. cheers George On Thu, Mar 2, 2023 at 7:33 AM Shumon Huque wrote: > > Hi folks, > > We've posted a new draft describing the former "Black Lies" mechanism > for authenticated denial, now renamed as "Compact Lies". > > https://datatracker.ietf.org/doc/draft-huque-dnsop-compact-lies/ > > We are hoping to discuss it here and at IETF116, and see if there is > interest in adopting the work and publishing it. We feel that it deserves a > stable published specification since it is now one of the dominant forms > of authenticated denial deployed amongst the commercial online signers > today (notably Cloudflare, NS1, and Amazon Route53). > > The draft includes the NXDOMAIN/Empty Non-Terminal distinguisher > mechanism I described at IETF 111 ( > https://datatracker.ietf.org/meeting/111/materials/slides-111-dnsop-sessb-black-lies-ent-sentinel-01 > ) and currently implemented > by NS1. > > Christian and I are currently discussing some tweaks to that mechanism > which we will broach in a separate email thread shortly. This thread can be > used for general comments on the topic of the draft. > > George Michaelson, in private email to me, has expressed the view > that we shouldn't be calling these mechanisms "Lies" any more (I'm > sure he will elaborate if he is inclined). I'm personally okay with that, and > if > there is agreement, we could just call this Compact Denial of Existence, > and discard the "Lies" meme. > > Shumon > > ___ > 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
[DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
Hi folks, We've posted a new draft describing the former "Black Lies" mechanism for authenticated denial, now renamed as "Compact Lies". https://datatracker.ietf.org/doc/draft-huque-dnsop-compact-lies/ We are hoping to discuss it here and at IETF116, and see if there is interest in adopting the work and publishing it. We feel that it deserves a stable published specification since it is now one of the dominant forms of authenticated denial deployed amongst the commercial online signers today (notably Cloudflare, NS1, and Amazon Route53). The draft includes the NXDOMAIN/Empty Non-Terminal distinguisher mechanism I described at IETF 111 ( https://datatracker.ietf.org/meeting/111/materials/slides-111-dnsop-sessb-black-lies-ent-sentinel-01 ) and currently implemented by NS1. Christian and I are currently discussing some tweaks to that mechanism which we will broach in a separate email thread shortly. This thread can be used for general comments on the topic of the draft. George Michaelson, in private email to me, has expressed the view that we shouldn't be calling these mechanisms "Lies" any more (I'm sure he will elaborate if he is inclined). I'm personally okay with that, and if there is agreement, we could just call this Compact Denial of Existence, and discard the "Lies" meme. Shumon ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
