Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

Warren Kumari <warren@kumari.net> Fri, 23 July 2021 20:19 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012163A16C0 for <dnsop@ietfa.amsl.com>; Fri, 23 Jul 2021 13:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7Cia9WY_Wof for <dnsop@ietfa.amsl.com>; Fri, 23 Jul 2021 13:18:56 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807573A16C7 for <dnsop@ietf.org>; Fri, 23 Jul 2021 13:18:56 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id m13so3920978lfg.13 for <dnsop@ietf.org>; Fri, 23 Jul 2021 13:18:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/aOzkRY3lvQUMSfDSwjK7UKHUtUyNUhVvJ8yhTb/1LU=; b=O1Mn+dgUNJ3Bsxja0ML+J+AnjXZqUbA5A6wW60Wo1G0ORVbkdF6Fj72crvWrVf7bwu 0XcGy4j/ME1CvmSC8Tozofdq7HqGKQO1jxR602H7feHMwvNviZV562Jzhp0b1SWAwDkt 2u8E3jLqaVRKBLnX97pfHKMkfWWnHEZo78TQ+sYOTPPWNpg4E6Ectc5E6y6PunkiwZ7C sc2LwkaeVcmBSObSvMJN+pV8B5bh5KFmxvqmPV6rY4nvJOPlHbuFEW9ryhaTTDroHUWg gpeA3CjGd5DDkcgOHqrHMtN7HYu3UFy7tQwjdcJsHjzSY52LYLf9WexmOfYlDJhG0D2g fsUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/aOzkRY3lvQUMSfDSwjK7UKHUtUyNUhVvJ8yhTb/1LU=; b=McTijB9MLKgOrdQMDu8NiCr1rGiMmrshDobLjgBwtJeuWxJXfsTcoTqFvr5ZoBQnkq 3XZsYcwx/CdWrUqQKRffMw5sy8bxV4FSv847gcXhQNeBHXxvo0F+Pjtja/Yb9tulOhiD Z005m6o5yVNdx1Tfgvws30w1Ot9NKVpB2dXdkm6KpAIjmfYTxYtaNMpg7T7648swr7fx R+LOv2581PV7nVP5YBUGLY3zlzr7Ay3KkU8sljz2VAeHECGXeF2YE4f5miH4iEm7I7gf dgRYoJ5J3dfKreCSZYeNoGQ9ornl4vn+EDtd3n3BUaFcM1JUaKSF58sGpqSuOOZKwqQH M8YQ==
X-Gm-Message-State: AOAM531RBXYvFl85nYEssQt72ixirdQ5sB21ohVYHry6MYB1nzcAZ5DD zxeMgzlJY0AEzzCIOjkVQRKYWtCqstrV/ZjpNqpfKg==
X-Google-Smtp-Source: ABdhPJxzCQJ13kHf+nP8mK2BvbwLmzk4a1lDiV4NT/GCxGdZcSp8541eXvlnSpL67/hCO2TnAPLcKnHZzLMMDEv0JHE=
X-Received: by 2002:a05:6512:3296:: with SMTP id p22mr4023669lfe.543.1627071532950; Fri, 23 Jul 2021 13:18:52 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com> <0ed6efa6-c981-fa64-472c-eef0c5453f4a@isc.org> <CAH1iCipP2C0fPgFYBGeR3Esvzf4eMxVv+EJKgKkfSiVX3MCqnA@mail.gmail.com> <c225cb3d-7682-4bf0-831d-c841540d1f74@isc.org> <CAH1iCirP64PV1a7mAqUgi0mrg05WJySy8jq62HiEUuftQEF2TA@mail.gmail.com> <832f7712-1dc3-e563-f98e-8ec0ede25577@isc.org> <73FDFFF0-5C05-45B5-82C1-0D909219DFAF@dukhovni.org> <CAH1iCir53=pEvz+3Nhc6+pL0PWb8Dv7cSNkBU32xj7zVqKn-Sw@mail.gmail.com> <b1b82cce-a9c0-212a-6eba-301a257e5884@isc.org>
In-Reply-To: <b1b82cce-a9c0-212a-6eba-301a257e5884@isc.org>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 23 Jul 2021 16:18:17 -0400
Message-ID: <CAHw9_iJLaSZibHhgG__wTW1H-sDHN=gKOHaxzy64fJy2bW1f3w@mail.gmail.com>
To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <pspacek@isc.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PsOgzfgtXzXceaHDNwSCY-aU0N0>
Subject: Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jul 2021 20:19:02 -0000

On Wed, Jul 14, 2021 at 4:17 AM Petr Špaček <pspacek@isc.org> wrote:
>
> On 14. 07. 21 5:13, Brian Dickson wrote:
> >
> >
> > On Tue, Jul 13, 2021 at 10:01 AM Viktor Dukhovni <ietf-dane@dukhovni.org
> > <mailto:ietf-dane@dukhovni.org>> wrote:
> >
> >      > On 13 Jul 2021, at 6:22 am, Petr Špaček <pspacek@isc.org
> >     <mailto:pspacek@isc.org>> wrote:
> >      >
> >      > As Viktor pointed out in
> >     https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/
> >     <https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/>
> >     , it seems that this problem plagues roughly tens out of 150k
> >     domains he surveyed. I think this makes further discussion about
> >     _necessity_ of the workaround kind of moot.
> >
> >
> > The plural of anecdotes is not data... unfortunately.
> >
> > So, I don't recall who presented it, where, or when, but it was some
> > time in the last couple of years, maybe at an IETF or OARC meeting.
> > But, the gist of the presentation was that the presenters studied query
> > sources from a number of vantage points, over a period of years, and
> > concluded there are approximately 3 million resolvers.
> >
> > Those resolvers are not all directly connected to the Internet, and
> > some/many are configured as forwarders (with potentially multiple
> > forwarders in chains/trees).
> >
> > The point here is, that Viktor represents one out of three million
> > vantage points, which undoubtedly have different characteristics in
> > terms of resolver software and version, and intermediate servers (e.g.
> > forwarding to resolvers, or forwarding to forwarders).
> >
> > Additionally, Viktor's data set was TLSA, which is already a niche set
> > that is self-selected to be on DNSSEC-signed zones, meaning relatively
> > new and mainstream code bases (possibly over-generalizing admittedly.)
> > Examining larger data sets on domains that are not DNSSEC-signed, may
> > show a different prevalence of the ENT problem.
> >
> > The other distinction is that the problems leading to bad ENT results,
> > may not be on the authoritative servers, but may be in front of them
> > (close to the authoritatives), or may be other middle-boxes closer to
> > the resolvers, or between forwarders and resolvers, etc. Thus the scope
> > of the ENT problem may vary based on the vantage point being used to
> > collect results.
> >
> > Thus, in the absence of any statistically meaningful data, I disagree
> > with the mootness of the issue.
> >
> > That doesn't mean we can't reach consensus, of course, and given that
> > this is a -bis document, and we are discussing how to handle the corner
> > case of underscore ENTs, some focus should be given to the impact rather
> > than the prevalence. This includes both the impact on code paths, and on
> > the effects to client apps affected by ENT broken-ness.
> >
> > It may be helpful to note that the draft itself already differentiates
> > behavior by the number of labels, in section 2.3 (in a MAY context)
> > using the MAX_MINIMIZE_COUNT logic. Thus, if an implementation is
> > already doing that work, adding underscore handling might not be a large
> > burden (and might mesh nicely in terms of coding). For example, in
> > evaluating the break-points when partitioning the labels to limit the
> > total number of queries, the sequence COULD treat any contiguous
> > sequence of underscore labels as if it were a single label, and then do
> > its partitioning of labels using the same relative logic.
> >
> > The main point being, if the implementer is already doing anything other
> > than literally iterating over all the labels one at a time, under all
> > circumstances, then adding underscores into its handling isn't likely
> > significantly burdensome.
>
> Maybe, or maybe not. We cannot know for sure until it's implemented in a
> real resolver. In my experience, major resolver implementations contain
> little but important details that make even seemingly simple tweaks way
> harder to implement than it looks on paper.
>
> Not having running code to support this proposal this late in
> publication process is IMHO another reason why it should stay at MAY level.

Thank you everyone for the discussion.

As this is after WGLC and IETF LC, I'd want to see a very strong and
clear consensus before requesting a change from MAY to
SHOULD/RECOMMENDED... and I simply don't see that.

However, one of the big things that we wanted from this discussion was
to make sure that implementers consider if this is an optimization
that they want to perform, and seems that that has occurred :-)

Unfortunatly I made a stupid error when sending the initial note - I
said: "I'd like a **clear** input, on this question only, by Tuesday
August 13th.".
I intended to ask for feedback by **July 13th**, but August 13th is my
birthday, and so it seems that mental autocorrect took over...

Whatever the case, I'll progress this to IESG Eval. What with IETF
scheduling and such, it won't show up on the telechat before the 13th
(if there is somehow clear consensus to change before that, we can
adjust the dates, etc...)

Thanks again for the useful (and constructive!) discussion,
W

>
> Petr Špaček
>
>
> > The difference between the many-labels problem and the underscore
> > situation, is the difference between weakness against attacks and
> > inefficiency (many labels), versus actual brokenness (for some
> > indeterminate fraction of the namespace from some indeterminate portion
> > of the resolvers on the Internet).
> >
> > I'm hoping to advance the discussion even if no one is persuaded.
> >
> > Brian
> >
> >     Full disclosure, I only tested TLSA records.  I can't speak to what
> >     one might expect with SRV or other record types.  Yes, failures are
> >     not that common, for what is worth another example:
> >
> >     https://dnsviz.net/d/_tcp.mail.ncsc.de/YO3DpQ/dnssec/
> >     <https://dnsviz.net/d/_tcp.mail.ncsc.de/YO3DpQ/dnssec/>
> >     https://dnsviz.net/d/_25._tcp.mail.ncsc.de/YO3Bsw/dnssec/
> >     <https://dnsviz.net/d/_25._tcp.mail.ncsc.de/YO3Bsw/dnssec/>
> >
> >     Here the "A" query for the ENT was unexpectedly "REFUSED". :-(
> >
> >     If implementations at least seriously consider the advice to treat
> >     special-use labels *specially*, I'll declare victory...
> >
> >     --
> >              Viktor.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

--
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra