Re: [Doh] on blackholing resolver-associated-doh.arpa and resolver-associated-doh.arpa

Joe Abley <jabley@hopcount.ca> Wed, 27 March 2019 10:30 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72BC1202BE for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 03:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 EZrewOXSdan4 for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 03:30:22 -0700 (PDT)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369DD120294 for <doh@ietf.org>; Wed, 27 Mar 2019 03:30:21 -0700 (PDT)
Received: by mail-wm1-x342.google.com with SMTP id w15so1283385wmc.3 for <doh@ietf.org>; Wed, 27 Mar 2019 03:30:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GqJUqFfQ1wytt1kC5+2Ivjh8ZWXx4cyMN+BkerND0sw=; b=AKw4P9if6FOcuQpTgPOAg52MJ5QKu9Js3WV74xLuowqrd3bBokaYSGskcF3DjJcNN2 jHy49Cenl5gyigAtrLItUiNysgtxExp0eQB7qQndIOvV4GtPBp4VclNNlmnJLRM63eFk +iTWZwSoZLII9zrVD/8XK4angaUtkJSOOVMlQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GqJUqFfQ1wytt1kC5+2Ivjh8ZWXx4cyMN+BkerND0sw=; b=Iw+COjKo8SN+ljADnLmuAjWzpq7UirSEZdV7mBmap/dvcJl3joqeVlJArE5xSjkvk0 OcG6a9YeE2Q9lU6fg7Mk4jdOcOLSArEfUC2lhRlUXp4mhEwpBMuSjNq20Ajrnp671K4y wg2IA+Pz26eFncuRnd8BYnnMIonneP4hKa1IQyooGlb9rECPfdQNWprJWCqh9ZvNzAVj ZGaiAe267bICuXR5mZLx0OD4wxZ/+49U8YMMhpPIjHa5GOqGycbGhKdpvaQb+1Uk7r4P 4oUuGJ3T5zXC/1JTr5joJNpbpEMg1ZUrIVLfJ4h2wtzUCw8q0Hmtl8xX2y3ZCnZc+hgP xJqA==
X-Gm-Message-State: APjAAAXwwN0kx1hIBlG4b2dAKZoRazZ9V0y8F1kxWhcszbEmM07/Ajqx nvTBM02plLmWSSkNSlu6oh3cjw==
X-Google-Smtp-Source: APXvYqxmtaEpAAPdb40J/wGbmQ14BTuTJhbNs1yLSm7zZ2/+Dxb7OR455g0iKmUphFqH4b89KOUxoA==
X-Received: by 2002:a1c:9cd1:: with SMTP id f200mr17333454wme.91.1553682619494; Wed, 27 Mar 2019 03:30:19 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:b9cf:782:7eb9:e729? ([2001:67c:1232:144:b9cf:782:7eb9:e729]) by smtp.gmail.com with ESMTPSA id q26sm20523793wmc.6.2019.03.27.03.29.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 03:30:18 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <22AA82AA-7EA4-413F-B154-A38F8CA36306@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_927AC060-3EDC-4DD5-85AE-95B33A2E8B01"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 27 Mar 2019 11:29:46 +0100
In-Reply-To: <CA+9kkMBCeecLFOk3eG6WzSdG9icBEme_G4hUxVXM=kuqfio+cw@mail.gmail.com>
Cc: DoH WG <doh@ietf.org>
To: Ted Hardie <ted.ietf@gmail.com>
References: <E064E7E9-0E00-4B3E-8841-59EB40B4EEDD@hopcount.ca> <CA+9kkMBCeecLFOk3eG6WzSdG9icBEme_G4hUxVXM=kuqfio+cw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/yLWX_ZdLwJf7fb1HvauQGEAgNag>
Subject: Re: [Doh] on blackholing resolver-associated-doh.arpa and resolver-associated-doh.arpa
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2019 10:30:26 -0000

Hi Ted,

On 26 Mar 2019, at 16:31, Ted Hardie <ted.ietf@gmail.com> wrote:

> When I sent the text (as requested), I just grabbed a copy of the text from  RFC 8375, Section 7.  That suggests pointing to 'blackhole-1.iana.org <http://blackhole-1.iana.org/>.' and 'blackhole-2.iana.org <http://blackhole-2.iana.org/>.'  which the AS112 project augments.  The issue that these were built to solve, a high load of queries to .arpa for queries leaking into the zone, seems like it might apply to this special use name.

I am familiar with the AS112 project. The crucial difference between the junk PTR queries for RFC1918 and RFC1918-like nets that are soaked up by those servers and the two ARPA domains we're talking about here are that the threat models are very different. It's a stretch to imagine that a rogue PTR response can cause anybody any harm, whereas a rogue response to these doh queries could subvert all subsequent name resolution in a way that would be difficult to detect, and there is the potential to do so on a large scale.

> DNAME is theoretically possible instead, but the .arpa server operators  have historically been slow to take up the idea of using DNAME (they did not agree for .home.arpa).  I have no objection to trying again, of course, if that is preferred.

My DNAME observation was simply to illustrate that the blackhole idea was inconsistent with the current text in the document. I'm aware of the practical problems of using DNAME in ARPA in the way that it is currently managed.

> I agree that there is a possible issue here, and I would support documenting it.  But since the basic trust model I'd suggest for a doh server discovered this way is equivalent to "something scrawled on the wall of a coffee shop", I think this situation (in which they are not recognized locally as special use names, and the particular anycast AS112 server answering the leaked query is an attacker) is pretty much par for a pretty rough course.

I think the risk is far more serious than you are implying, and to be honest I think the only useful advice here is that the mechanism should be considered harmful and must not be used.

Since the meeting this week also seemed to expose concerns about the other two mechanisms, it's seems possible that this draft has led us down a dead end.


Joe