Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-00.txt

Ben Schwartz <bemasc@google.com> Wed, 30 October 2019 01:10 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84382120059 for <dnsop@ietfa.amsl.com>; Tue, 29 Oct 2019 18:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2OsOk8FUtPf for <dnsop@ietfa.amsl.com>; Tue, 29 Oct 2019 18:10:53 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 2C3DD120052 for <dnsop@ietf.org>; Tue, 29 Oct 2019 18:10:53 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id r144so555884iod.8 for <dnsop@ietf.org>; Tue, 29 Oct 2019 18:10:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ta/fckcMMYEJAwI7rMUD2CzVXQ5n3CnPP8S7ne/GHR4=; b=BVCazLDO5J7k5R188UVvCM8pLG0pMA3UOwLXI8DxPPZeGVoQDvEYJ408vk0u1+eILo yx/U2jHHqWRu9NRTTQbk5vukJGYzXc/iw+7Y4SxfmFRflSTK5FlyPsEmlB2pFkQ3P/BP 9+oIJE0LGPOGdEh0ioJ6urAsB3q/vtfWLB6WlbhF/DI+Xi7TYs289Sv5nBVf6u+yfXUQ t8no/1+ns7OM/MxsD3jrsurK+ouiKdGNJTDwaT2w8tfpMBo7RvtZVALdOl7sKZnE4vlk VKOTRPUPFtBlH3RR2raC0xH6tJinuO1vzsSNI3V9GRSpMNLxphECY6j7OlrEpv/Up+Ju 9j0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ta/fckcMMYEJAwI7rMUD2CzVXQ5n3CnPP8S7ne/GHR4=; b=M9f9UlFRbGSKJbqT8FjCJkekvUQTfoH03wEwAGAcQipMLQyBGG3bJEO1UEbuI9GU6j j7kfg+JlesNFGUNWaZK93dwR3loRBtDb7dlFkuiK9Wfn7Iy2smwntC66cHJ02aYj02CJ cAiLFhKs05LwKXBlf5jiXluOIcVVesFyvIc1UtSH6uc8P4Zoj8b67YxKy1/1tPyxEaNX La79BcWogZI2uLqpe6WZOt8+1LXkOwDwYsrMlpqo8JVwMF7+x/J0OFerHJb9Hs/LG5Rj t/q0HimUPeErYVGJzcsBuztSOz3lehv4lLLwACUYrvizcQ3ITdPf3cWitPuydo0QAr4W a7lw==
X-Gm-Message-State: APjAAAXGgpIDubgXeXn97lVdrlGk/b/V/FO4wisOVRMqd1ncJIsM1r/M 5wN8ZOB/ywqlO5YLFbQnmyA0Tkt25gYfRdHVAOdttA==
X-Google-Smtp-Source: APXvYqwhG3bfKyuhxR5fSmI0TZTbOPTzlErNadqt3fki0iZxGgLDRWfDNza/+uA0no1GVAzIT1cWHNPligj+H36osk0=
X-Received: by 2002:a02:3796:: with SMTP id r144mr26311677jar.49.1572397851948; Tue, 29 Oct 2019 18:10:51 -0700 (PDT)
MIME-Version: 1.0
References: <156624288737.19884.5252170663574668911@ietfa.amsl.com> <A8482079-FC91-414D-B0EF-E016606E9093@noware.co.uk> <34CACD4F-554A-4736-BD53-36D980B5A5A5@noware.co.uk> <CAMGpriWD_dOADk4=OKFzVZn8KT9RC_A1v3jQDq6oDLuRB3K9yg@mail.gmail.com> <CAHbrMsCng7tG=qNjDv23xzRU+_-_QD-4a_NvKzGDAHmGO4PA5Q@mail.gmail.com> <54A6311E-E688-4357-AC14-8A9ACBC1D6FF@noware.co.uk> <alpine.LRH.2.21.1910291903230.1249@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1910291903230.1249@bofh.nohats.ca>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 29 Oct 2019 21:10:40 -0400
Message-ID: <CAHbrMsD3mpb_DbMm1s9J=fp1u_YEoJfiQRDM5LugAKu-9ph7bg@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: Neil Cook <neil.cook@noware.co.uk>, Erik Kline <ek.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000074b8e90596166782"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1ePWZxlVqcs8sXKFcYe6q9ca0H8>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2019 01:10:56 -0000

On Tue, Oct 29, 2019 at 7:04 PM Paul Wouters <paul@nohats.ca> wrote:

> On Tue, 29 Oct 2019, Neil Cook wrote:
>
> >       FWIW, I've previously stated a preference for dropping the use
> of ".well-known" entirely, and using draft-00's "resolver-info.arpa" name
> instead of reverse-IP, in order to improve support for
> >       passive forwarders.  I understand this was changed in the hope of
> offering some kind of security here with DNSSEC, but I think it's unlikely
> to work in practice, and we're better off keeping
> >       things simple.
> >
> >
> > I completely agree. I’d much rather see something like
> "resolver-info.arpa" instead of reverse-IP.
>
> Throwing DNSSEC under the bus for a "simpler" name seems rather
> excessive. I for one would like to see DNSSEC in the reverse
> support when possible. For a future where not everything is
> chained to a single all-powerful LetsEncrypt root CA.
>

The concern here is not "simplicity" as such.  The main concern is the
large fraction of devices whose configured DNS server is actually a
forwarder (usually with an RFC 1918 address).  Even if the actual recursive
implements RESINFO support, these devices will not be able to retrieve the
information, because they won't be querying the reverse address that the
recursive resolver thinks it owns.

This can be solved if the forwarder implements some sort of RESINFO query
rewriting, but it certainly won't work for the existing install base.  I
think this is the crux: should the upstream RESINFO be available through a
naive forwarder, or only through a forwarder that actively works to support
RESINFO?  I prefer the former, because I think serving the existing install
base is worthwhile.

I don't see significant value in DNSSEC for this application, because an
adversary who can forge DNS responses (the DNSSEC adversary) can also forge
DNS configuration messages (DHCP or RA).  What good does it do me to prove
that 1.2.0.192.in-addr.arpa is authentically publishing this RESINFO, if
the attacker forged the DNS configuration message that said 192.0.2.1?


> Paul
>