Re: [DNSOP] Question about usage of ip6.arpa and in-addr.arpa

Ted Lemon <mellon@fugue.com> Tue, 13 March 2018 15:38 UTC

Return-Path: <mellon@fugue.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 25092127419 for <dnsop@ietfa.amsl.com>; Tue, 13 Mar 2018 08:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.416
X-Spam-Level:
X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DRUGS_ANXIETY=1.483, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 QJZIePk3pttt for <dnsop@ietfa.amsl.com>; Tue, 13 Mar 2018 08:38:49 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 91C2D127522 for <dnsop@ietf.org>; Tue, 13 Mar 2018 08:38:49 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id a23so39066qtm.4 for <dnsop@ietf.org>; Tue, 13 Mar 2018 08:38:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IULNww5YFTHEEuWolovjndlCNb0aWEk3INw8UxLTcK8=; b=LO6g0NQ0sl9o17n41L8hD1WRZg9RcC/Zx7iKwHXoIU8NV43qsCXBcio+rMBHhCoGnU Ok8MFJ5pmbayB5KLF35mJjj3Y4daUjn4an68OJ7wNbAEKMo0bEc4kPTMFfudMMzS9l8x Zhs1dw77Pu4NkXLoTqqpA6Bjp7QDINGdZ0LhgfFo3Nz4friNL6+2Psln9Zq3/CIBrzWH zc8EC0c8F2HEbVKixZpIrR0ReJAl0InmsvlyA/yesjtZPuCzhJ4epPkCEKlhEQ16YRVT 49p/OXL2jJCcsAw+0q+l1zo6O6OrEKRiUPz9etkDmUp+2yM3nKVQJ5KFUqbJjBhRfzCQ 7X4Q==
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=IULNww5YFTHEEuWolovjndlCNb0aWEk3INw8UxLTcK8=; b=lknpZ48S//lnFhUWFWdX1I/339g13tOLKvOGs+Nl7NjZSdW2eULzkQ1UTO4ZC0z3zR ZDiqh9kC9lc3DzsgNTBJ/wtYyqDXoE7L9bnmN2iaWDmNIEVFdh7icUq8oRQwPA+2xeIv f+eVP93+JcVPhcjRZdjYFCXnGy6VqsNDFVlLY77WeonIb/PHyb1rTSQcq1MtGrQy+RaZ rbFcLjf8MG+XxD4NfffRa4DGnJAbkvWbOA2D9rGabE3SxLHNWW56DthK2ee5w7k0PmQB Bcbks0pysC8Wt4cJlBPxY/PAIV3NTkOFieCI+E6EPNRDQ0AR8HNxpvj/wMBcHOaBodGK ZSFw==
X-Gm-Message-State: AElRT7ExoLZqrnygLuJGEA6pdjTlX8zHqbZA1GzEbq1T+8WqIYFkJutp AF5rhTnrlEYURw7511QKmW7vVg==
X-Google-Smtp-Source: AG47ELsZEYyt9YBVNm5hzph2KgBQEPoEouOeIvHJIndeps+6cVszlY8QmxwFm57bSN4Jnuym4tyCbw==
X-Received: by 10.237.51.69 with SMTP id u63mr1791895qtd.52.1520955528628; Tue, 13 Mar 2018 08:38:48 -0700 (PDT)
Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id c52sm374572qtc.89.2018.03.13.08.38.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 08:38:48 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <644A11A0-93BB-4599-B2F6-2014A142DDC3@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_845F301E-B95C-4535-AAB4-CE1DB6EAA561"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 13 Mar 2018 11:38:46 -0400
In-Reply-To: <AB681FB4-205C-4B75-8E9D-4AEAC69EF6A6@90.212.199.in-addr.arpa>
Cc: dnsop@ietf.org, Roland Bracewell Shoemaker <roland@letsencrypt.org>
To: Joe Abley <jabley@90.212.199.in-addr.arpa>
References: <B7531E71-AC04-4D40-86B0-74F2DCA92446@letsencrypt.org> <62E857A4-6184-4F1A-A6E2-16AC5C16F574@90.212.199.in-addr.arpa> <21FCA497-026E-4602-85CA-8A823084961F@fugue.com> <AB681FB4-205C-4B75-8E9D-4AEAC69EF6A6@90.212.199.in-addr.arpa>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LdOVW32eWqhs6iWmVBOWP33SQT0>
Subject: Re: [DNSOP] Question about usage of ip6.arpa and in-addr.arpa
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 13 Mar 2018 15:38:51 -0000

On Mar 13, 2018, at 11:27 AM, Joe Abley <jabley@90.212.199.in-addr.arpa> wrote:
> The canonical service that is difficult to use (or at least bootstrap) by name rather than address is the DNS. If we imagine the intersection of the DNS and TLS to be non-zero, there's your use case. This was Paul's point.
> 
> DNS resolvers are normally referred to by address. This does imply a need for address stability, and a lack of the kind of agility that is possible in other services. People who have renumbered popular resolvers whose failure has real end-user impact are nodding right now. And possibly checking their pockets for valium.

Indeed.

But I don't think you actually answered my question.   I get the idea that in theory, DNS servers are configured this way.   But we are talking about a situation where the resolver is contacting a service over TLS because, one assumes, privacy is important, or the local network is filtering DNS, or something like that.

So now, where is that IP address coming from?   DHCP?   That doesn't match the trust model.   You must be connecting to a server that you know, or else there's no reason to prefer it to the local resolver.   

If it's a server you know, you should do the trust establishment ritual when you configure it.   So the trust establishment nugget needs to contain both a name and one or more IP addresses, not just an IP address.   Problem solved, no need for new technology, other than to specify what the trust establishment nugget looks like.

So the interesting problem is how the server with which the host has already established trust signals that its IP address is going to change at some time in the future, so that the host resolver knows to switch IP addresses.   It's not how to establish trust on an IP address.   If you have to establish trust on an IP address, you've already lost.