Re: [Tsv-art] [Last-Call] [DNSOP] Tsvart telechat review of draft-ietf-dnsop-dns-error-reporting-07

Paul Wouters <paul@nohats.ca> Wed, 14 February 2024 03:31 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD6CC151552; Tue, 13 Feb 2024 19:31:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=nohats.ca
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 r_WPVK_yEQxn; Tue, 13 Feb 2024 19:31:47 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093D6C151542; Tue, 13 Feb 2024 19:31:46 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4TZNz31lMMz1Hc; Wed, 14 Feb 2024 04:31:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1707881503; bh=asRCRozai9Nhkr/9S9HOyIVGx7gtA1kHMGneCCIVQKg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MdgRBwBlvNan8HBOf8YpyHTBEoFVoLdfzjd+GFn+zvnm7ZbREmJUe64Ib6P0U3DmK CaYoAnnOR65oaK1B5wK2+reM811AM0FKiyQ/D4XKui39IPsomLcy0GFzn5DsZO+WO7 pUkElqNCxIGTG+/Jow/zNs1TkHE1nCYDncZQxHZY=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id pntlMdm3OhpM; Wed, 14 Feb 2024 04:31:42 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 14 Feb 2024 04:31:42 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3A8D9112238F; Tue, 13 Feb 2024 22:31:41 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 36FC5112238E; Tue, 13 Feb 2024 22:31:41 -0500 (EST)
Date: Tue, 13 Feb 2024 22:31:41 -0500
From: Paul Wouters <paul@nohats.ca>
To: Roy Arends <roy@dnss.ec>
cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsv-art@ietf.org, dnsop <dnsop@ietf.org>, draft-ietf-dnsop-dns-error-reporting.all@ietf.org, last-call@ietf.org
In-Reply-To: <73358628-DFCD-4048-A3D7-FFA2BCF3573D@dnss.ec>
Message-ID: <8558549e-6967-1f5b-df6b-23c2785d2ba6@nohats.ca>
References: <170195243214.35471.15139593366465856989@ietfa.amsl.com> <73358628-DFCD-4048-A3D7-FFA2BCF3573D@dnss.ec>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/aqSMN_RRpGNyH3G_XSInJC6Qq5Y>
Subject: Re: [Tsv-art] [Last-Call] [DNSOP] Tsvart telechat review of draft-ietf-dnsop-dns-error-reporting-07
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Feb 2024 03:31:51 -0000

On Wed, 14 Feb 2024, Roy Arends wrote:

>> 1. There is a recommendation to use DNS COOKIEs [RFC7873] over UDP (PS), but no
>> statement about how to mitigate the effects when these are not used. What ought
>> someone to do when this is not done?
>
> It is recommended that the client (the resolver) sets the DNS COOKIE. The benefit of using cookies is for the client. It is to make sure that the response is genuine.

Does it? Not for an on-path attacker that sees the COOKIE in the clear.
So what attack does this really counter?

And if using TLS, then one wouldn't need a COOKIE anymore to prove genuineness.

> However, there is little value in the response. The actual value for error-reporting is to the authoritative server that may have an issue.
>
> When cookies are not set, or are not used, there is language that states the following:
>
> The monitoring agent SHOULD respond to queries received over UDP that have no DNS COOKIE set with a response that has the truncation bit (TC bit) set to challenge the resolver to re-query over TCP.

This sounds more like an attempt for a mechanism for the monitoring agent
to determine that the incoming report is not send from a spoofed address,
but it wouldn't work like that. Setting the TC would work, provided the
client comes back. Or if the monitoring agent would demand a COOKIE
before answering (even if the answer is not the actual data the resolver
wants anyway). If the monitoring agent requests a COOKIE, it would force
the resolver to resend with the COOKIE, proving it is not just a spoofed
packet. But that would always result in double the load to the
monitoring agent.

> I hope this is sufficient.

I'm not the person this was written for, but now I an actually confused
what the purpose of the DNS COOKIES is.

Paul