Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sun, 10 April 2022 22:00 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FC83A11CD for <dns-privacy@ietfa.amsl.com>; Sun, 10 Apr 2022 15:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.316
X-Spam-Level:
X-Spam-Status: No, score=-1.316 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, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=9AVLncDm; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Exrc7aoa
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYrxHUXlOhtS for <dns-privacy@ietfa.amsl.com>; Sun, 10 Apr 2022 15:00:15 -0700 (PDT)
Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE13C3A11C4 for <dns-privacy@ietf.org>; Sun, 10 Apr 2022 15:00:15 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1649628013; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=MpUpBerc4qyr2jyCplQ70MxBpO1vnRgKuqasyB4Yiac=; b=9AVLncDmQCuVY/6VFpP76V2G0Q/qr958BpN/9vLOCJVv5X4ZQgyWZLsjhqErsGwYXJjKI edpxCiSiiYSYywBBQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1649628013; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=MpUpBerc4qyr2jyCplQ70MxBpO1vnRgKuqasyB4Yiac=; b=Exrc7aoaTMMHV9EwuKl8W3v/jsifc+eijD3/L0EXL7jqU3ngFJiFVcJtrWNoTQPNq62QN B+aBlZy4lCLSEyfYHnPHs0c/IsVD04zjLadmrixXOFzz14dGT/GpnJPHlSjs/WG+SRmZiUP qdFWyUwF+a1PIj3KSA3wGtvGeFHl1dVDke3iHhJQlMDnR+aQUfjljiRQfOkvUpZXR6EV7ca LXvjfldvo8Kp172zfo8drNQAcsPKwG3ejPA419bMDHn5ilLn0AHcY2V/OUHU7B0a5ui2yH+ 8Y0+LIJpO7+oYOwmtkilNRwt6cJJoQUBGXygPzfA7YXnBIBemfolmPrb4cqg==
Received: from fifthhorseman.net (2603-8000-df00-593c-0c5d-9165-325b-66aa.res6.spectrum.com [IPv6:2603:8000:df00:593c:c5d:9165:325b:66aa]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 82920F9B0; Sun, 10 Apr 2022 18:00:12 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id F3186202B7; Sun, 10 Apr 2022 15:00:05 -0700 (PDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Christian Huitema <huitema@huitema.net>, Sara Dickinson <sara@sinodun.com>, dns-privacy@ietf.org
In-Reply-To: <743bea81-873a-7099-3a6b-e894103a4a85@huitema.net>
References: <164667566033.16942.15407079409764144071@ietfa.amsl.com> <F923A397-81EA-4C6B-87C9-571168FBE6E1@sinodun.com> <87ilrgkjjs.fsf@fifthhorseman.net> <743bea81-873a-7099-3a6b-e894103a4a85@huitema.net>
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Sun, 10 Apr 2022 15:00:03 -0700
Message-ID: <87zgksmwf0.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/BWtBEylS8IkgnKpPpKI9bBR8WPk>
Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2022 22:00:21 -0000

On Sun 2022-04-10 11:57:40 -0700, Christian Huitema wrote:
> But Sara has a point, we should give servers a way to control the
> deployment.

Authoritative servers do have a way to control deployment: they can
simply refuse connections on encrypted transport.

Rather than refusing arbitrary connections haphazardly on the basis of
time of arrival (or some other unrelated feature), though, maybe we
should offer guidance on how to selectively refuse connections on the
basis of the client IP address (to avoid state-flapping on the recursive
resolver side).

I've noted this as
https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/22

> Servers could very well be flooded with queries just after starting to 
> test DoT and DoQ. We should address that by changing the server 
> responses, not the client queries. For example, we might want to define 
> an extended DNS error message rejecting a query because the capacity to 
> process encrypted requests is exceeded. And we might want to specify 
> that clients receiving such messages should stop unilateral attempts to 
> use that server for a while. DoT or DoQ servers could use that to 
> progressively enable the service for a fraction of their clients, maybe 
> using some kind of filter based on the client's IP.

I'd be game to use this document to define such an extended error
message, but i don't understand how its semantics would differ from
merely rejecting the connection attempt with an ICMP Port Unreachable
message (which non-implementing authoritative servers will send anyway).

In a strongly-authenticated protocol, the difference between an extended
DNS error code and ICMP Port Unreachable would be that the client could
rely on the authenticity of the DNS error code (ICMP Port Unreachable is
of course always spoofable by the network path).  But in this
opportunistic deployment, both signals are spoofable.

Maybe the concern is that the authoritative server implementation might
not have control over the full stack enough to respond ICMP Port
Unreachable to a specific subset of client IP addresses.

In that case, i can imagine two distinct modes of operation:

- the server only has the opportunity to respond after the TLS/QUIC
  handshake is complete.  In this case, i don't see why the server
  shouldn't just go ahead and handle the query; some part of the stack
  has already borne the connection setup costs.

- the server can respond early during the TLS/QUIC handshake.  In this
  case, we'd want to define an error at that layer, so that the
  authoritative server can signal failure without incurring any
  additional connection costs.

Does this analysis seem right to you?  Or is there a reason that i'm
missing that an authoritative server would want to have the signal at
the layer where a extended DNS error message would make sense?

     --dkg