Re: [DNSOP] [ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error] Client requests including empty EDE isn't currently interoperable (Issue #26)

Joe Abley <jabley@strandkip.nl> Fri, 26 May 2023 09:34 UTC

Return-Path: <jabley@strandkip.nl>
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 B5CD1C151548 for <dnsop@ietfa.amsl.com>; Fri, 26 May 2023 02:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strandkip.nl
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 oytgDomeV3oE for <dnsop@ietfa.amsl.com>; Fri, 26 May 2023 02:34:32 -0700 (PDT)
Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) (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 EF691C151525 for <dnsop@ietf.org>; Fri, 26 May 2023 02:34:31 -0700 (PDT)
Date: Fri, 26 May 2023 09:34:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=protonmail; t=1685093669; x=1685352869; bh=SNT7Dfc5fBoNnUW/XJwy/IK/cHlISp3uagyq1MqPLUE=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=aJYdUSQOqwlqHNP+TTOYnGaNW/qmDQ2df5cr2XWfGt3sFSiYPcAjCCRmL095dxvEM WoxbofASLTLdclq2jaBqnrXSHvvdTU7bWVkhWJCq8NG4DCniI9fyzG4h8buk/5r+ZB GErhe7+Sl/WdvXokSs25Yw+uUqYfaUmVrubNkUlsuon1nWsy6dqpDaznF7KbAp9oFU fvMszhWYmJtwaRFLca4aIUlXhFczBGMfkEZUnkA9ZQAWEaXO3cjRMlInYoKtJwWOqC pzohY1u3ih4GlwaTX6xQ5QS6B3qde1dwxpuR+LImZMXXL30PLm8ufNmEVyhM+4kuED v1mViSWmtOfRg==
To: dnsop@ietf.org
From: Joe Abley <jabley@strandkip.nl>
Message-ID: <HyggU_pmFyle3baAUSk83JXNZhovfK1e58DkLywsWRtlkM6vRFMruXBjSKu5E4ufvUHj2SFK87MIyUcTrX3WLENeeTBKWcPcOA71Y-dGT68=@strandkip.nl>
In-Reply-To: <ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/issues/26/1560142346@github.com>
References: <ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/issues/26@github.com> <ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/issues/26/1560142346@github.com>
Feedback-ID: 73263797:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_33mWvZSB7Ox2y2EnrbCMl1LW3FnIgWsG6GGUJugDbQ"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pkA_YKLm8jQ4Cvp8EAHql7mLbZY>
Subject: Re: [DNSOP] [ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error] Client requests including empty EDE isn't currently interoperable (Issue #26)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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, 26 May 2023 09:34:36 -0000

[This arrived the other day from github, and I don't know what kind of mess I will make if I just group-reply to it, so I'm following up on the list. List seems better for general discussion anyway.]

On Tue, May 23, 2023 at 23:25, Dan Wing <[notifications@github.com](mailto:On Tue, May 23, 2023 at 23:25, Dan Wing <<a href=)> wrote:

> The justification for signaling draft-ietf-add-resolver-info is in Security Considerations where it currently says:
>
> An attacker might inject (or modify) the EDE EXTRA-TEXT field with an DNS proxy or DNS forwarder that is unaware of EDE. Such a DNS proxy or DNS forwarder will forward that attacker-controlled EDE option. To prevent such an attack, clients supporting this document MUST discard the EDE option if their DNS server does not signal EDE support via RESINFO [I-D.ietf-add-resolver-info]. As recommended in [I-D.ietf-add-resolver-info], RESINFO should be retrieved over an encrypted DNS channel or integrity protected with DNSSEC.
>
> should we soften that? The authors have argued back and forth on the risk of this attack versus deployment, code, and operational complexity of draft-ietf-add-resolver-info signaling.

RESINFO provides a statement of intent about what you can expect from a particular resolver service. I am not convinced it is an adequate substitute for a negotiation of capabilities between the endpoints of a DNS transaction.

For many significant DNS servers that we arguably care most about troubleshooting problems with (and hence where extended error codes might provide the most benefit) the particular server (host, process, implementation) that handles a query sent to address A is usually not the same server that handles the next query sent to the same address.

The root servers are an example of a set of servers that use anycast with intentionally-different DNS implementations deployed in different places. Most resolver clusters relied upon by any significant population of clients are not single instances of software bound to an address on just one host interface.

Software and metadata (in general) is routinely released incrementally, meaning that the software running on one particular origin server in an anycast deployment is not in general the same as that on other servers, and cannot always be expected to behave the same (otherwise you would never be able to roll out or roll back new features).

EDNS options are attached to a particular response and refer to that self-same transaction, which is why they are a good choice for things like EDE, NSID, buffer negotiation, etc.

(NSID is an improvement over CH/TXT/HOSTNAME.BIND or CH/TXT/ID.SERVER for the same kind of reasons that I'm waving my hands about here.)

Information published by RESINFO (or by other means disconnected from the transaction about which information is required, on a web page maybe, on a mailing list!) seems like good input to a human troubleshooting expedition but a poor choice for a client that is trying to make real-time, automated decisions about how to handle a request for name resolution.

I think perhaps this risk and its suggested mitigation need some more thought.

(I'm not actually sure I agree this is a risk that needs a mitigation.)

Joe