Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

Roy Arends <roy@dnss.ec> Mon, 10 July 2023 20:04 UTC

Return-Path: <roy@dnss.ec>
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 C6EEEC16B5AD for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2023 13:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=dnss.ec
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 nhOdmt7Cqf75 for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2023 13:04:54 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 DD514C131810 for <dnsop@ietf.org>; Mon, 10 Jul 2023 13:04:53 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-765a4ff26cdso445299885a.0 for <dnsop@ietf.org>; Mon, 10 Jul 2023 13:04:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; t=1689019492; x=1691611492; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/0+dtyexK9L5uUuy8LOMqWxHaXmP066GZA4BtypnCVg=; b=dRniNhQeNsjRKoGXK/qw8ftYVmdEg2ziLmko5V3JuKd79SEys0LUx2rDb8wwa7NyPg YO8FpXlcxgd6z2wLDQvvnyRE5fywcCV3WBbbes1XoTI8hcfUR+IFrbLmKAAnIHsFN8kc l42ejs2I3somCq0AjFyP0NEkh6ElxbtzlNeWs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689019492; x=1691611492; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/0+dtyexK9L5uUuy8LOMqWxHaXmP066GZA4BtypnCVg=; b=P/acbPFTzcQ1U7ennOoBP6jFPrUWvE2xrfjBJHPHxoDBa/dhneyyuhT+b0g97Zl6in r/q2Obs7DdOqRR4mTdA6YT5GZ0jXZRIfnXSv8M2UbLb+RZuKYBZGQWLgDt5j0dch/GRh 82o1PYxnNtqoXX9VgZ+BwgFfK9fDBmfOsUZ+qeY+KlYJDXysaV5PEsEYozSkeArYvN4P CoawCKFKQVW0FSwjRKJsWdvSs9vn46tRFEyDXDGIa2Axm9p5V95m0Hb35XVlI4eVvZ54 EmeZ1zkzsnQQAiZcQALh+qw2fw53u2fDId9/d1+caYhEHy1DD8Y/7lUCQ0dpJY3S3Fca oLZw==
X-Gm-Message-State: ABy/qLYw9Sfl8cv8EV7wwFh9RmTPlalS26Gt3B8EVMPSTTBhSPJjEuV5 FeFZJaN/uIsW9D3NLGpwHYiP6ZoYQgqHhltCgiT8Pg==
X-Google-Smtp-Source: APBJJlGVVEwd5F1RO27kWJCwsDNdykxAFWQ+fwrNSU+eSwUPQADdEVu4IXOC/nJ7QyksUcNMAJIL4A==
X-Received: by 2002:a37:b486:0:b0:767:3e13:6017 with SMTP id d128-20020a37b486000000b007673e136017mr11835218qkf.30.1689019492577; Mon, 10 Jul 2023 13:04:52 -0700 (PDT)
Received: from smtpclient.apple ([89.33.15.144]) by smtp.gmail.com with ESMTPSA id n24-20020a05620a153800b00767b37256ecsm190100qkk.107.2023.07.10.13.04.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2023 13:04:52 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Roy Arends <roy@dnss.ec>
In-Reply-To: <BN8PR15MB32811A729AA0F3D979C7B6EBB323A@BN8PR15MB3281.namprd15.prod.outlook.com>
Date: Mon, 10 Jul 2023 21:04:39 +0100
Cc: Benno Overeinder <benno@nlnetlabs.nl>, DNSOP Working Group <dnsop@ietf.org>, DNSOP Chairs <dnsop-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A239D77-84E1-40EE-B4C6-62555A0DCB8E@dnss.ec>
References: <fa6ec641-0eab-dec6-2267-3ca818402812@NLnetLabs.nl> <BN8PR15MB32811A729AA0F3D979C7B6EBB323A@BN8PR15MB3281.namprd15.prod.outlook.com>
To: Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wKZEZDv62gQzhNMIne0ZKTW4ldw>
Subject: Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
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: Mon, 10 Jul 2023 20:04:58 -0000

Ben,

Thanks for this! Comments inline.

> On 23 Jun 2023, at 02:27, Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org> wrote:
> 
> I want this draft to move forward, but upon review I noted with concern the security section text:
> 
>    DNS error reporting is done without any authentication between the
>    reporting resolver and the authoritative server of the agent domain.
>    Authentication significantly increases the burden on the reporting
>    resolver without any benefit to the monitoring agent, authoritative
>    server or reporting resolver.
> 
> Strong authentication (e.g. to a zone identity with DNSSEC) is probably excessive, but the current draft appears to have no defense against even trivial IP spoofing.  Anyone in the world who can spoof IP addresses can impersonate a reputable resolver and pollute the error reports sent to authoritative servers.  As an authoritative server operator, I would place a lot more trust in reports from reputable resolvers than from unrecognized sources.

Ack

> I think the draft should probably say something like: "To defend against spoofing of source IP addresses used for error reports, reporting resolvers MUST use DNS over TCP [RFC 7766], DNS COOKIE [RFC 7873], or another procedure that defeats IP address spoofing."

I’ve added language to this extend. However, I’ll won’t go as far as MUST. I’ve made this is a SHOULD (for both TCP and cookie), while the authoritative server SHOULD respond with TC bit set to force a re-query over TCP. 

Hope this suffices.

Warmly,

Roy


> --Ben SchwartzFrom: DNSOP <dnsop-bounces@ietf.org> on behalf of Benno Overeinder <benno@NLnetLabs.nl>
> Sent: Thursday, June 8, 2023 5:59 AM
> To: DNSOP Working Group <dnsop@ietf.org>
> Cc: DNSOP Chairs <dnsop-chairs@ietf.org>
> Subject: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
>  !-------------------------------------------------------------------|
>   This Message Is From an External Sender
> 
> |-------------------------------------------------------------------!
> 
> Dear DNSOP WG,
> 
> The authors and the chairs feel this document has reached the stage 
> where it's ready for Working Group Last Call.
> 
> This starts a Working Group Last Call for: 
> draft-ietf-dnsop-dns-error-reporting.
> 
> Current versions of the draft is available here: 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ .
> 
> The Current Intended Status of this document is: Standards Track.
> 
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please 
> speak out with your reasons.
> Supporting statements that the document is ready are also welcome.
> 
> This starts a two week Working Group Last Call process, and ends on: 
> June 22nd, 2023.
> 
> Thanks,
> 
> -- Benno
> 
> _______________________________________________
> 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