IETF Logo Mail Archive

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

Roy Arends <roy@dnss.ec> Wed, 14 February 2024 09:43 UTC

Return-Path: <roy@dnss.ec>
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 5A51DC14F6A8 for <tsv-art@ietfa.amsl.com>; Wed, 14 Feb 2024 01:43:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=unavailable 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 lN1Wv1eXiIFQ for <tsv-art@ietfa.amsl.com>; Wed, 14 Feb 2024 01:43:11 -0800 (PST)
Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (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 BE67DC14F609 for <tsv-art@ietf.org>; Wed, 14 Feb 2024 01:43:10 -0800 (PST)
Received: by mail-oo1-xc2f.google.com with SMTP id 006d021491bc7-5957ede4deaso3233884eaf.1 for <tsv-art@ietf.org>; Wed, 14 Feb 2024 01:43:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; t=1707903789; x=1708508589; darn=ietf.org; 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=74JHw4iu1mnrBs+z0gKgCkJK7DS9AuDJ0Bb+IosfqXw=; b=I1K4Dy58XtbI16lvuXbmip61dhRXxuLcAjwzrFo1n+OUePYI+E7iWO6oFRXDGk9SVB 9Qgud9kWlsz5r3CjbIpKkvKQpPURyyyJUK9yuBo4rwqFR1rGTPGM/vxIH9gxPsUEy9No Ddad8lIzJuE6e0+QnfEf6QsB3tz0YuNQyv4e0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707903789; x=1708508589; 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=74JHw4iu1mnrBs+z0gKgCkJK7DS9AuDJ0Bb+IosfqXw=; b=WWAOoL+TcXg/EVSz1dL0EVTRH765hqjmcs7wMxb6id2GHUBt5huDOXA5el1No5DjvZ FCwrWCVeozLqL7fpq7JuybIVplfm3JCpzzdom4FZuLxurEaxkUUaGf+CUEz13qu+xxrt ew2L3eqNQQXFYoHD7o3lLEjT+fIwgT6/ed/eoPkZHBT6RastK6y11LuGbbsnTS1VW2Vb qiRTygq5FQMXfKeGnS3Y5zkDuJ2NwMrsih22632GYh241VgB/lCkyg919uLFySpwGC49 qnGUEwAB/SYuJa+D7n3VZfxH33MYyoixqakVTL8Q6zP+G9rH2P+WZU/WtBakCu/GgkI5 gyqg==
X-Forwarded-Encrypted: i=1; AJvYcCXL8M0KHfx6eigaQDtDBb2xwzu+ia1ozaH5C4x/qiBPs2jgJtIRLJfEzXmlf653T6exVyRJqBMKpfpE1NGAw2Ye
X-Gm-Message-State: AOJu0YxzsvdZNwP8N8vKkAmMaURxJ2vAAzr0tAcmtc45cX/N0hfQA09J /VUiBT/+23g0XcfMysD6uckMRTAfjL9BYuWl5uBWiXu7ayF/x85pbDaHQ2Y5SUE=
X-Google-Smtp-Source: AGHT+IHoO99IcP4T7KpCaRldihQtainb67qCVVGYlhWqMA+TxXUFt+/ggwJjiqrnyI2AbdF6NKTjEQ==
X-Received: by 2002:a05:6358:e490:b0:178:62d5:dafc with SMTP id by16-20020a056358e49000b0017862d5dafcmr2334763rwb.18.1707903789337; Wed, 14 Feb 2024 01:43:09 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCW5b/hBw9uAQbHHV/zaHqJPnkN/m7QW6zFvapJVQjEkaB98mV5HLL3BzIoUNv4zLQJateCfu6HsthylFCsxjbwszOEYkNtpaUPdS0mr9JY7I4VBQwZkt0bU8NVvbfLaS2K660r7NYYNnxzT8E+x0fszP2Ji6/Ye55veMeb1TiiZ9Fug8faBEON2DVGAvgOtkY40tz49GvGOko9CcKrfhihyASwxOg==
Received: from smtpclient.apple ([78.111.198.85]) by smtp.gmail.com with ESMTPSA id r25-20020a639b19000000b005dc89142b99sm2400314pgd.84.2024.02.14.01.43.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2024 01:43:09 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
From: Roy Arends <roy@dnss.ec>
In-Reply-To: <8558549e-6967-1f5b-df6b-23c2785d2ba6@nohats.ca>
Date: Wed, 14 Feb 2024 09:42:53 +0000
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
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F8E9601-0839-4DAA-A524-A322133187B1@dnss.ec>
References: <170195243214.35471.15139593366465856989@ietfa.amsl.com> <73358628-DFCD-4048-A3D7-FFA2BCF3573D@dnss.ec> <8558549e-6967-1f5b-df6b-23c2785d2ba6@nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3774.400.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/hXSfzlb-5-y2CEFJn1YarR0BgcQ>
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 09:43:16 -0000


> On 14 Feb 2024, at 03:31, Paul Wouters <paul@nohats.ca> wrote:
> 
> 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?

Ah, no, apologies, it doesn’t. (I’ll blame this on my DNSSEC muscle memory). I should know better. I’ll try again:

There is text in the document that specifies what the monitoring agent should do if cookies are not used:

Section 6.3:

  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.


> 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.

A cookie may be set due to an earlier transaction, no?

Roy

v2.23.0 | Report a Bug | By Email