[DNSOP] DNS, censorship, attacks and centralization
Mark Nottingham <mnot@mnot.net> Mon, 19 May 2025 07:03 UTC
Return-Path: <mnot@mnot.net>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id D6EC72A0D901 for <dnsop@mail2.ietf.org>; Mon, 19 May 2025 00:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b="T7AL+tSm"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="cCxKB5e6"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCePRWzVqsCm for <dnsop@mail2.ietf.org>; Mon, 19 May 2025 00:03:46 -0700 (PDT)
Received: from fout-a4-smtp.messagingengine.com (fout-a4-smtp.messagingengine.com [103.168.172.147]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 265352A0D8FA for <dnsop@ietf.org>; Mon, 19 May 2025 00:03:46 -0700 (PDT)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfout.phl.internal (Postfix) with ESMTP id 042A613801FC; Mon, 19 May 2025 03:03:46 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Mon, 19 May 2025 03:03:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1747638226; x=1747724626; bh=/99W7DWekWRx7dW683oiU1ZmOigt3xyDDND+qXEwtTE=; b= T7AL+tSmTPAH6qHNHozXfErSCiwMzx1EMqq5igR0qydyo/fcGKRWfaZWiLbiHtHY /AH/F13gDC47GkSg9qW36iUDsQf7DMNkQ5VlUioMMG3qoJAUo2ufPf+Z0v5EYb9Q Vg8yp/Ktx1do6utAD2bCa4gTFnheaEsOFxDzBWkIskSMhHzBhLRLYGDaS1Eg+POF 42sWZ5XtShyYB+itEIIAK7yLCqrI3qC/ZWgJ/EIW5t/MBajsfnxVSRRt278AwU9e 2M1E4HClnko2Cm90LkQRDFD7IENWZMRN8r8+sdj+OhcIrgQcrrkxnYeesl+8xb5/ V/aiqcFMRLW7j79NMKz8RA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1747638226; x= 1747724626; bh=/99W7DWekWRx7dW683oiU1ZmOigt3xyDDND+qXEwtTE=; b=c CxKB5e6iiEb6OlERxvqOx1h5z+nZHnS9qTYcq68ojqZS2KKkDF1s6jSMt8FQDk1T qK5Z6kxxFxohQkAPcvSd2SpJbq7kQpge2k0/ABSaE9W0RQ6TBmVri2cnSrd6AuEO btvQkK9oz7gleYJ4PIbveyt6lJJB2dCAaHXMXfQd2/MR6lx/tfCPcS1v2XJR//wT 48L6YOF7VMwZRfNwEiGs2nVHi32cNnSIIRRcF+RyhYkqq4WQOk8NkUXkoMORp8su ms2D8NcRRpWP6sfDI3uinlwnUkzVgGxOWjMAibUKyTI992Bq7OtXYloyvcLO9F6/ /Wug52c85nWzwICgxNHRg==
X-ME-Sender: <xms:0dcqaFYSutGeIzntRrkm5LqGE5oHAwBcr9YebmFCxr0QVLfW_XlA-w> <xme:0dcqaMYu8Tt6L2Y2agsKILIgN8xDZBMc0LufI2IB7GQ16EFE5Gy0MupkDL7aF6hFk ypJLFXa_DC00V7TvQ>
X-ME-Received: <xmr:0dcqaH8mn_-fzXmBjAGfMspTf7gEdCeCxed_cIe-1pzOn4Ef2nm7oC3mNpMokoBuSBxOocdcSnojVgwQjt4CY_4O4RVV_EUhxbCsqw6bmSkB7HqOVbeuZsw9>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdefvddtjeefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurheptggguffhjgffvefgkfhfvffosehtqhhmtdhh tdejnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhoth drnhgvtheqnecuggftrfgrthhtvghrnhepfefhhfelleejjeejieekhfejfeeiheetgeej gffhudegveeigeehgefftdetudetnecuffhomhgrihhnpehmnhhothdrnhgvthenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhn ohhtrdhnvghtpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtph htthhopehprghulhesnhhohhgrthhsrdgtrgdprhgtphhtthhopegunhhsohhpsehivght fhdrohhrgh
X-ME-Proxy: <xmx:0dcqaDrqULcVm3g6U7wE_DvtvSd0z2oEvMJLyMqcl_9ax3sgkMu18A> <xmx:0dcqaAqbnzVJT1bLOKS43ndfC3phusmBs9Jk931tuEoNyu3_MJM_jQ> <xmx:0dcqaJSbXlQsYd6leiM5upNinpMJlGf_tgwgrGSzSrugJQBSrMgA7A> <xmx:0dcqaIrHHCOoDlyHcpgIBu3T1j0I3wNFn5jwvBcE5PsdFUYJSd9WpA> <xmx:0dcqaMaQ_Xoc5RkULNVNvCjmcfxo1igZQcpy8esSy7D9jK9LbSXM2htu>
Feedback-ID: ie6694242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 19 May 2025 03:03:44 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CB55AFC1-633F-47B8-9E50-063430A4E7AF@nohats.ca>
Date: Mon, 19 May 2025 17:03:40 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <135700F9-CA5E-45FF-959F-803CF393191C@mnot.net>
References: <CAFpG3gcrWH3w-SgNuk9qx6HL2iZkpWJDRTBEtNToSf6J5mG7wQ@mail.gmail.com> <CB55AFC1-633F-47B8-9E50-063430A4E7AF@nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3826.500.181.1.5)
Message-ID-Hash: 4HTDTAZW2QX5Z4DGROXOEUUV2UFC54TE
X-Message-ID-Hash: 4HTDTAZW2QX5Z4DGROXOEUUV2UFC54TE
X-MailFrom: mnot@mnot.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] DNS, censorship, attacks and centralization
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/g1oVpBZwB-UjDuuhsx0ml3_xuhM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
Dropping last-call and others from distribution... > On 12 May 2025, at 8:54 pm, Paul Wouters <paul@nohats.ca> wrote: > >> The draft explicitly recognizes this risk and includes guidance to mitigate it. Specifically, as discussed in the Security Considerations section: >> “A client might choose to display the information in the 'c' field to the end-user if and only if the encrypted resolver has sufficient reputation, according to some local policy (e.g., user configuration, administrative configuration, or a built-in list of respectable resolvers)...” >> This is intended to prevent clients from blindly displaying contact information, such as those found on potential attacker-controlled networks. > > But the draft is just punting this problem from the protocol specification to the protocol implementers. It’s not only the contact data but also the extra text that’s a freeform text attack vector. >> >> >> The goal is to preserve user safety by ensuring that only trusted resolvers can supply user-facing details. > > As previously said, this creates a central choke point of trustee dns that works “better” then untrusted dns and causes centralization of dns followed by centralization of censorship. This seems like a good place to focus discussion. First, two things that I don't _think_ are being disputed: 1. Surfacing censorship events to end users is desirable, because it a) avoids user confusion / misattribution of the problem, and b) allows end users to be more fully informed. This is becoming a more urgent problem, thanks to current events. 2. Allowing untrusted network elements to display messages to the end user is an attack vector that needs to be mitigated. If anyone disagrees with either of the above, please say so. (2) leads to designs where the ability to display messages is gated somehow. Both my draft and (AIUI, based upon the above) the structured DNS error draft have a notion of 'trusted' DNS resolvers that has privilege over 'untrusted' DNS resolvers, as a mitigation to this kind of attack. Paul, you say above that this approach can lead to outcomes where there is centralisation in both DNS and censorship. I agree that doing so creates a different experience -- users of 'trusted' resolvers will presumably see clearer error conditions when censorship is happening. However, whether that difference amounts to an advantage that is so great that it creates overwhelming pressure to use such resolvers is questionable. Many users will be unaware of the difference at all; even those that care about censorship only benefit to the degree that they know censorship is happening. There is no economic or functional advantage beyond that knowledge. Even if such pressure does eventuate, it's questionable that it would result in centralisation -- i.e., whereas those DNS resolvers would become more of an effective choke point for control than they are today. That's because users can easily switch between resolvers if they choose to; DNS is a standard protocol with multiple implementations and multiple deployments. Today people can (and do) use their ISP or other local network resolver, use a public resolver, or deploy their own resolver. Note that I'm using 'centralisation' in a way that's distinct from 'concentration' -- but again, even if the concern is concentration in the DNS resolver market, it's hard to see this information making a significant difference in that market. Yes, some censorship-aware folks might decide to deliberately configure a DNS resolver, but that's hardly going to move the needle on concentration. If I'm missing something here or otherwise misjudged it, please point out what/how. If someone has an idea for a way to mitigate (2) in a different fashion, I'm all ears. You also talk about 'centralisation of censorship.' I'm not sure what you mean there, but am guessing that you're concerned that censorship might become easier, based upon: > Will the “trusted” DNS start refusing the .gl TLD soon because of a mad king ? If that's the case, I don't see how proposals along this line change the outcome. If a government in a given jurisdiction wants to censor, they will censor. Providing a mechanism for resolvers to making the details available to citizens who are affected by that censorship so as to inform their participation in the democratic process (assuming they're lucky enough to live in a jurisdiction that allows that) is the best we can do. When I started this work, I had a latent concern that defining mechanisms like this would encourage censorship because it 'blesses' a path for courts (etc.) to use. We're well past that now -- courts, legislatures and policymakers around the world are now regularly blocking content using a variety of (often technically bad) methods. The best outcome is one where that activity does as little collateral damage as possible, and its operation is made as clear as can be to those who it affects. Cheers, -- Mark Nottingham https://www.mnot.net/
- [DNSOP] Re: Comments from IETF Last Call about dr… Stephane Bortzmeyer
- [DNSOP] Comments from IETF Last Call about draft-… Eric Vyncke (evyncke)
- [DNSOP] Re: Comments from IETF Last Call about dr… Stephane Bortzmeyer
- [DNSOP] Re: Comments from IETF Last Call about dr… Petr Špaček
- [DNSOP] Re: Comments from IETF Last Call about dr… Paul Wouters
- [DNSOP] Re: Comments from IETF Last Call about dr… tirumal reddy
- [DNSOP] Re: Comments from IETF Last Call about dr… tirumal reddy
- [DNSOP] Re: Comments from IETF Last Call about dr… Peter Thomassen
- [DNSOP] Re: Comments from IETF Last Call about dr… tirumal reddy
- [DNSOP] Re: Comments from IETF Last Call about dr… Peter Thomassen
- [DNSOP] Re: Comments from IETF Last Call about dr… tirumal reddy
- [DNSOP] Re: Comments from IETF Last Call about dr… Paul Wouters
- [DNSOP] Re: Comments from IETF Last Call about dr… tirumal reddy
- [DNSOP] Re: Comments from IETF Last Call about dr… tirumal reddy
- [DNSOP] Re: [Last-Call] Re: Re: Comments from IET… Paul Wouters
- [DNSOP] Re: [Last-Call] Re: Re: Comments from IET… Eric Rescorla
- [DNSOP] Re: Comments from IETF Last Call about dr… S Moonesamy
- [DNSOP] Re: Comments from IETF Last Call about dr… S Moonesamy
- [DNSOP] Re: Comments from IETF Last Call about dr… David Adrian
- [DNSOP] Re: [Last-Call] Re: Re: Comments from IET… tirumal reddy
- [DNSOP] Re: [Last-Call] Re: Re: Comments from IET… tirumal reddy
- [DNSOP] Re: [Last-Call] Re: Re: Comments from IET… Paul Wouters
- [DNSOP] Re: Comments from IETF Last Call about dr… Petr Špaček
- [DNSOP] Re: Comments from IETF Last Call about dr… Petr Špaček
- [DNSOP] Re: Comments from IETF Last Call about dr… tirumal reddy
- [DNSOP] DNS, censorship, attacks and centralizati… Mark Nottingham
- [DNSOP] Re: Comments from IETF Last Call about dr… Petr Špaček
- [DNSOP] Re: DNS, censorship, attacks and centrali… Bill Woodcock
- [DNSOP] Re: DNS, censorship, attacks and centrali… Jens Finkhäuser
- [DNSOP] Re: DNS, censorship, attacks and centrali… Ben Schwartz
- [DNSOP] Re: DNS, censorship, attacks and centrali… Mark Nottingham
- [DNSOP] Re: Comments from IETF Last Call about dr… tirumal reddy
- [DNSOP] Re: DNS, censorship, attacks and centrali… Mark Nottingham
- [DNSOP] Re: DNS, censorship, attacks and centrali… S Moonesamy