Re: [Add] draft-ietf-add-resolver-info-09

Steffen Nurpmeso <steffen@sdaoden.eu> Tue, 20 February 2024 19:30 UTC

Return-Path: <steffen@sdaoden.eu>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4740C180B43 for <add@ietfa.amsl.com>; Tue, 20 Feb 2024 11:30:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIOOQ6gmB01l for <add@ietfa.amsl.com>; Tue, 20 Feb 2024 11:30:28 -0800 (PST)
Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8BCC151078 for <add@ietf.org>; Tue, 20 Feb 2024 11:30:26 -0800 (PST)
Date: Tue, 20 Feb 2024 20:30:23 +0100
Author: Steffen Nurpmeso <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: tirumal reddy <kondtir@gmail.com>
Cc: Mark Andrews <marka@isc.org>, add@ietf.org
Message-ID: <20240220193023.t8iYjP8Z@steffen%sdaoden.eu>
In-Reply-To: <CAFpG3gd5GwSAoOs3SX2xWZyKVR7F5y-y1VxxbTmfooC4AWo5Mw@mail.gmail.com>
References: <7F756639-9CB4-4F1A-9F77-C47101CE292A@isc.org> <CAFpG3gd5GwSAoOs3SX2xWZyKVR7F5y-y1VxxbTmfooC4AWo5Mw@mail.gmail.com>
Mail-Followup-To: tirumal reddy <kondtir@gmail.com>, Mark Andrews <marka@isc.org>, add@ietf.org
User-Agent: s-nail v14.9.24-598-g53c2ea4337
OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt
BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs.
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/jNHJiK52HkaaOJvmdbZCtE76c-I>
Subject: Re: [Add] draft-ietf-add-resolver-info-09
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Feb 2024 19:30:29 -0000

tirumal reddy wrote in
 <CAFpG3gd5GwSAoOs3SX2xWZyKVR7F5y-y1VxxbTmfooC4AWo5Mw@mail.gmail.com>:
 |On Thu, 15 Feb 2024 at 06:02, Mark Andrews <marka@isc.org> wrote:
 |> Why is it necessary to change the standard processing of queries for
 |> RESINFO when we already have a signal (AA=1) about whether the answer
 |> is coming from elsewhere or not ?
 |
 |It is introduced to handle a scenario where SUDN is used to discover the
 |encrypted resolver, and if the discovered resolver does not support
 |RESINFO, it will forward the query upstream. An attacker might provide a
 |RESINFO response with AA=1. The proposed mechanism aims to help the client
 |identify whether the response is coming from the discovered encrypted
 |resolver.

By the way i am really not worth being noted for anything
acknowledgeable regarding the work of this WG.  At all.
If you have another iteration of the document, i would prefer if
you would simply scratch my name from your work.
It is solely your work, for sure.
And the above is possibly very smart: my DNS work was two decades
ago, and i could not even tell whether i have ever seen authority
section entries being passed through or not.

My main topics are simplicity so small teams can still exist
competetively as was true over two decades ago (ie, with knowing
the entire picture, not by delegating to "trusted" external
modules in uncounted numbers), when there were <3000 RFCs.

As such i very much appreciated RFC 8499, but i alone from my
superficial out-of-interest reading have 17 DNS-related RFCs
added locally since then, plus the draft of yours and whatever
else from this WG.

And a different way to get the TLS trust (or, rather, use existing
ways of various kind eg rpki, ikev2, or simply public keys as is
done by DKIM (certificates are a bit larger, but with the TCP that
is more and more needed per se, or QUIC; or even the permanent
HTTP proxying of everything, that is "no problem")) away from CA
pools, to DNS/TLS + DNSSEC zone records.  Thank you for that, too!

Ciao, and greetings from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)