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] IETF 116 Call for Agenda Items DNSOP WG
Dear WG, This is a Call for Agenda Items for the IETF 116 in Yokohama, Japan. Please email the chairs with your requests. *Or* drop us a pull request https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf116 look for dnsop-ietf116-agenda-requests.md. Please Note: Draft Submission Deadline is Monday 13 March 2023. See https://datatracker.ietf.org/meeting/important-dates/: 2023-03-13 Monday Internet-Draft submission cut-off (for all Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D Submission Tool https://datatracker.ietf.org/submit/. Thanks, Suzanne Tim Benno ___ 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
Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue
On Tue, Feb 21, 2023 at 5:50 AM Ralf Weber wrote:
>
> These “rare” cases where the domain is not resolvable when a glue is not
> present are the ones this draft is done for. So did you look how rare
> they were in your dataset? Being able to resolve instead of not resolving
> IMHO has value even if the number is not big.
>
> We all know that a lot of data in the DNS is garbage, that should not
> stop us from using the good data.
>
> So long
> -Ralf
>
The cyclic dependency based sibling glue (Section 2.3) is arguably
a bit of a corner case, and in past discussions some folks have expressed
the view that we shouldn't make accommodations to support it. I
think I can agree with that, but there were opposing views that we also
shouldn't break configurations that currently work. So it was left in.
The case of normal (non-circular) sibling glue, described in Section
2.2 is in my opinion useful though, and also extremely common - where
it isn't necessarily required for resolution but allows resolvers to obviate
additional follow-on queries (to the same servers) to obtain the sibling
glue.
Previous lengthy discussions on this topic indicate a consensus to
retain them, but not mandate their inclusion (or set TC=1 if message
size limits are exceeded).
Note that this document does not place any requirements on DNS
resolvers, so if a resolver implementer chooses to, they can ignore
sibling glue in referral responses, and/or explicitly fetch them.
As far as bad data, I agree with Ralph. It shouldn't prevent us from
being able to use the good data. My employer has tons of domains that
use (working) sibling glue.
There was extensive discussion previously about incorrect glue,
and other types of issues ("orphaned glue"), and what could be
said to get registries/registrants to cleanup referral data in
zones. But we were strongly advised by folks deeply familiar with
TLD operations to not try to tackle that can of worms here. The
draft does make the following suggestion though: "The IETF may
want to consider a separate update to the requirements for including
glue in zone data, beyond those given in [RFC1034] and [RFC1035]."
Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
