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

Roland Bracewell Shoemaker <roland@letsencrypt.org> Mon, 12 March 2018 17:40 UTC

Return-Path: <roland@letsencrypt.org>
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 8F27E126BFD for <dnsop@ietfa.amsl.com>; Mon, 12 Mar 2018 10:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org
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 5lNMRx8D8VO3 for <dnsop@ietfa.amsl.com>; Mon, 12 Mar 2018 10:40:55 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 246581200C5 for <dnsop@ietf.org>; Mon, 12 Mar 2018 10:40:55 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id s18so2637257wrg.9 for <dnsop@ietf.org>; Mon, 12 Mar 2018 10:40:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9yYAnDRqJ9Y0sOzFjeTxLqqxFwkOk5xF9ueesJ70ocg=; b=BJb3FmzM7es8ZBN6ZC89OcwoS1RIxLWolcnHZXJVjTdiIyLECAB+6HrgoknhqeVvdO QjGlqXO/oADWcPwoIPuQexr/Rld6KloIduHo04CRIDhInCloxGT4qngF+OqnSbN3PNup J4jbHv2YyiYZ5MO6mXNCBQX9od/GBIyhxSOW0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9yYAnDRqJ9Y0sOzFjeTxLqqxFwkOk5xF9ueesJ70ocg=; b=FJR32KuG0TuQ/4OC3pKQ+bghHzegjgwykFLpMh/Eksnv544wPcaOYlkFeiC/17nZgS mBXU2hKtexTtQ6s4NnCMM0HZMx/YqTfjiAtAqrQKQ/gpACujW9SBDWxGU+e5jCxXln4q OplYqSEUsyc/uIkp3fwmoR8Tar8goo7h/+Ffn2yjBqIdYTNAww1Qs7Xhgd8TJaleh+cE 5CbRV2DgOAbrulFKVYFCxJsmS849QmiWfQGuNN7gkcON+5rD/lraXvPsyqCHHiNZppvO FnG+ext00wIAkaIAbuIEVijPU6hfo6GdOv83R3/VNXm2y7t7RrhSUWDQ46jAvYZzsIhU hJ5g==
X-Gm-Message-State: AElRT7GtAypypvJ8/CqRcU5Z0Eiw4qy3jRu3freALYo9M/PEYGk5CI9j d+cb8aI53Tnnx5whLrY/DRfrxOTktJE=
X-Google-Smtp-Source: AG47ELvacacY3uy2QtvouCMXGkDYO2p2INv6hJhuMyuj2wZSbFanyQgdWTZDVNC/AEOAtSZm8z93kg==
X-Received: by 10.223.187.19 with SMTP id r19mr6819058wrg.110.1520876453533; Mon, 12 Mar 2018 10:40:53 -0700 (PDT)
Received: from [192.168.0.19] (cpc93784-hari17-2-0-cust1834.20-2.cable.virginm.net. [82.34.151.43]) by smtp.gmail.com with ESMTPSA id 2sm7145471wmk.29.2018.03.12.10.40.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 10:40:52 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Roland Bracewell Shoemaker <roland@letsencrypt.org>
In-Reply-To: <0EE4F82D-AD7B-4D50-B415-6B5558B7E974@vpnc.org>
Date: Mon, 12 Mar 2018 17:40:51 +0000
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4A5C84B-FD69-46B1-BD12-40DB56624FB9@letsencrypt.org>
References: <B7531E71-AC04-4D40-86B0-74F2DCA92446@letsencrypt.org> <0EE4F82D-AD7B-4D50-B415-6B5558B7E974@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/veE0Ww7qarh4IlX6wo2v83a4d-8>
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: Mon, 12 Mar 2018 17:40:57 -0000

The main use case here is for major providers who want to get certificates for addresses before there is actually anything bootstrapped on the machine behind it yet. Then they are able to immediately stand something up that can be used instead of needing to go through the process of validation and issuance etc. This typically is not something that individuals who do not directly manage their own DNS servers will use.

> On Mar 12, 2018, at 5:37 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
> On 12 Mar 2018, at 8:58, Roland Bracewell Shoemaker wrote:
> 
>> I’m working on a document in the ACME WG that concerns methods for validating control of IP addresses (draft-ietf-acme-ip) and wanted to see if anyone here could provide some input on a question I had regarding usage of the ip6.arpa and in-addr.arpa zones.
>> 
>> In the original incarnation of this document one outlined method revolved around requesting that a user place a TXT record containing a random token in the relevant ip6.arpa or in-addr.arpa child zone for the address being validated and then verifying that this record was present. After reading RFC 3172 there was some concern that this would not be a ‘blessed’ usage of the zones and that they should only contain records that related to mapping protocol addresses to service names. Because of this we reworked the method to require placing the TXT record at the target of a PTR record in the relevant zone instead.
>> 
>> After a number of discussions I’m interested in returning to the original concept as it simplifies a number of use cases that this document is intended to support but am still not sure whether or not this would be widely considered ‘ok’ by DNS folks. Obviously it’s entirely possible to do this as these child zones are delegated to users and they _can_ put whatever they want in them. Does this WG have strong opinions on whether we should/shouldn’t do this for technical reasons or we just being a bit too strict in our reading of 3172?
> 
> If the use case here is to be able to issue certificates for TLS servers based on the IP address instead of the domain name, creating something new in the DNS may be overkill. That is, why even have Section 4.1 of draft-ietf-acme-ip at all? What's wrong with only having direct HTTPS access?
> 
> --Paul Hoffman