[Doh] Comments on draft-hoffman-resolver-associated-doh-07

Alexander Dupuy <alexdupuy@google.com> Wed, 30 January 2019 15:20 UTC

Return-Path: <alexdupuy@google.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CFC1A130E46 for <doh@ietfa.amsl.com>; Wed, 30 Jan 2019 07:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.641
X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XVnz72r9InME for <doh@ietfa.amsl.com>; Wed, 30 Jan 2019 07:20:44 -0800 (PST)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 F1A41130E11 for <doh@ietf.org>; Wed, 30 Jan 2019 07:20:43 -0800 (PST)
Received: by mail-yb1-xb31.google.com with SMTP id x9so9742695ybj.5 for <doh@ietf.org>; Wed, 30 Jan 2019 07:20:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TgMNNF+lIY24C4P50+DdbaBjrZB8+bx+A4YrcsPfjq0=; b=IVElGnpId+1UveG6ERNaAfi8guuylg4Sha7eDj05fM8l5WXuZwSr1fNfh2pqUQVSIW m5C0vYmc9g/Q6X7C21ep77zOSsF/ZZgKoyrWNo1rTDYiY2kVlJiYCB8CeTIuo6gp/QEY HQ1od2C19fGvPvMbOeSP7Rbo0fKrAJ9F/fDivvrxpYZqNkZhn2XYbw1dRPDaCnZc+Ehj ayVU42/Zt/dshcnH56zyjOFmciXNdtSH3ZBjWp9BIR9xXI6T1oVIIRCnqirqAn4A0hDv KD0YSkdvzKw0V9I71UnuGWBC2NtTaNVEWSoHqdmJ8bdSC2eb2ef+akW/Ree8MLyNHJpw cLag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TgMNNF+lIY24C4P50+DdbaBjrZB8+bx+A4YrcsPfjq0=; b=TS5LmXygI+/X4z/8OSrRFUPMcxDrcdtj4+L8eyz98/jmGtVAgpGC67akxAQ35gdIZE pSs0Bzxl5yqHLMOsKV1dZHZWYPINlAFmJm9GrcSkL0znHjg2bS9yr9EMnzxRuPa5m9gH iN/65kHoi+ScPW2hO7xW8/r4Do8uZhKrOAV67hvLly8QmkAKZjIAczf0Dp+G4b8ULq47 jwm0gvpEEyRVwb7SxO07dbyAPnrRI6jy31qGOAhvq3GL50dlMWh1EXbebM72h2rWg6L5 NQR4dJ/Ed/z9mzn2zBhtGIaqfRH8n8DEY+Bpy8yPJPSdlj8QMKDCThTAdncnzDEPlqd7 yo9A==
X-Gm-Message-State: AHQUAuYtcJTrmuJexflVhR1wmyr6zyr//h7tR6GoXNCpiYMKJrJFigBN xXIzcuU8fN106MPFbz4oc19rg00h818c9CH8BiIj7HDjmAM=
X-Google-Smtp-Source: AHgI3Ia73HhhVhcZy0oa/Ku1R83zjMKXFwCRJjyr/oHw9nMo16QFf0qYVlPK17kqgc5a4e59Fe3cnXUw4NPM62oBruM=
X-Received: by 2002:a25:9808:: with SMTP id a8mr4051878ybo.59.1548861642474; Wed, 30 Jan 2019 07:20:42 -0800 (PST)
MIME-Version: 1.0
From: Alexander Dupuy <alexdupuy@google.com>
Date: Wed, 30 Jan 2019 10:20:31 -0500
Message-ID: <CAFdvYXdRtz5LgwBrSuLB-G9hYzC1fYwOtYZ3EHkbx9JFeJ1+yQ@mail.gmail.com>
To: doh@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000000d843a0580ae7445"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/EWkWKXu_ARP-3E0aZcL7KVnSMEQ>
Subject: [Doh] Comments on draft-hoffman-resolver-associated-doh-07
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, 30 Jan 2019 15:20:47 -0000

Not to derail the current thread on whether browsers or other applications
should use non-system resolvers, but as somebody working on a large public
resolver with experimental support for DoH, I have some comments on the
draft that a colleague encouraged me to share.

In particular, I'm concerned that the two Special Use Domain Names
(resolver-associated-doh.arpa and resolver-addresses.arpa) in draft-07
(henceforth just "draft-07 SUDNs") will get SERVFAIL when a forwarding DNS
resolver is performing DNSSEC validation, but does not support DoH or the
draft-07 SUDNs, even though the DNS resolver that it is forwarding to *does*
support DoH and the draft-07 SUDNs.

Attempts to resolve the draft-07 SUDNs in this scenario will get SERVFAIL
because the IANA Considerations section of draft-07 specifies that IANA
MUST NOT delegate the draft-07 SUDNs, and as a result, there will be no
proof of insecure delegation for those domains, nor any DNSSEC signatures
that would validate any answer other than the provable NXDOMAIN (using NSEC
records from the .ARPA zone). In this situation, somewhat like the
discarded approach of a special root domain record type, a DNSSEC
validating resolver will fail validation of any non-NXDOMAIN response. If
the forwarding resolver implements RFC 8198 (Aggressive Use of
DNSSEC-Validated Cache), it might well never forward queries for these
names at all, instead synthesizing an NXDOMAIN response from those cached
.ARPA NSEC records.

Perhaps this is intentional, but if so, it is inconsistent, since a
non-DNSSEC-validating forwarding DNS resolver in this scenario would pass
through queries and responses for the draft-07 SUDNs without any problems.
The scenario where a forwarding resolver is performing its own DNSSEC
validation is not common, but I know that it exists for some of our
clients, and it seems undesirable that they would see a different outcome
simply because they are being diligent about DNSSEC validation.

If this is not intentional (and the expectation is that any forwarding
resolver that wants to control DoH discovery in any way must do so by
handling the SUDNs used for this discovery), then another approach is
needed, one that doesn't depend on updates to intermediate
DNSSEC-validating resolvers.

Mandating insecure delegations in the .ARPA zone for those names (or better
yet, modifying the SUDNs so that they both would fall under a single
insecure delegation from .ARPA) would allow resolvers to create their own
responses that would not fail DNSSEC-validation. If there are political
reasons (reated to ICANN or IANA) that this can't be mandated for a new
subdomain of .ARPA, use of some other TLD might be an option, although it's
less desirable.

The insecure delegation NS records for the zone with the TXT and A/AAAA
records for the local resolver could either point to an AS112 RFC 7534
resolver name like blackhole-[12].iana.org or perhaps better,
blackhole.as112.arpa (which could serve a copy of the existing
empty.as112.arpa zone file for a new resolver-doh.arpa zone).

On the other hand, if it is explicitly desired that DoH discovery should
*not* pass through forwarding resolvers, then another approach that will
also fail even without DNSSEC validation by the forwarding resolver should
be used. I'm not sure what would be best in that case,. Historically, use
of queries with CHAOS class that will not transit a resolver is common, and
more recently EDNS options seem to be preferred, but neither approach would
permit identifying the resolver IP address in use when an application is
limited to using gethostbyname() library calls. Using a subdomain of an
existing SUDN like localhost might do the trick although there would likely
be a lot of variability in how that might or might not work (like the
draft-07 SUDNs, it would fail DNSSEC validation, but it would probably
still transit some resolvers that only special-case localhost and not
resolver-addresses.localhost or similar names). In the end, it might be
best to explicitly allow the resolver-addresses to transit (to an
insecurely delegated .ARPA domain), but use CHAOS or EDNS to get the
resolver's DoH information.

Alexander Dupuy |  Software Engineer |  alexdupuy@google.com |  +1