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

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Mon, 12 Mar 2018 15:58:33 +0000

Hey all,

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?

Thanks for the advice!
Roland

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 12 Mar 2018 10:37:27 -0700

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

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Mon, 12 Mar 2018 17:40:51 +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 <[email-masked]> wrote:
> 
> 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

---

From: Jim Reid <[email-masked]>
Date: Mon, 12 Mar 2018 23:12:36 +0000

> On 12 Mar 2018, at 17:37, Paul Hoffman <[email-masked]> wrote:
> 

Is web the only protocol that runs on the Internet now? I realise that might seem to be the case these days, but even so... :-)

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 12 Mar 2018 16:27:45 -0700

On 12 Mar 2018, at 16:12, Jim Reid wrote:

>> 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?
>
> Is web the only protocol that runs on the Internet now? I realise that 
> might seem to be the case these days, but even so... :-)

For which other protocols did you want certificates with IP addresses as 
identifiers? If your list is longer than zero, are you willing to help 
Roland with a solution using DNS records for validation that has any 
chance of being usable? (No smiley here.)

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Mon, 12 Mar 2018 23:41:10 +0000

> On 12 Mar 2018, at 23:27, Paul Hoffman <[email-masked]> wrote:
> 
> For which other protocols did you want certificates with IP addresses as identifiers?

I think these may be needed for SIP, particularly roving (nameless) clients. And quite possibly for P2P applications.

> If your list is longer than zero, are you willing to help Roland with a solution using DNS records for validation that has any chance of being usable? 

Yes, I’d be willing to work with Roland on at least finding and documenting likely use cases. Are you? Whether we (or others) can then come up with something that has any chance of being usable is another matter.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Mar 2018 23:43:52 +0000

On Monday, March 12, 2018 11:12:36 PM GMT Jim Reid wrote:
> Is web the only protocol that runs on the Internet now? I realise that might
> seem to be the case these days, but even so... :-)

we need to use TLS to secure both dns-over-https and some forms of TCP/53 in 
which the server's address is known but not its name.

-- 
Vixie

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 12 Mar 2018 17:07:16 -0700

On 12 Mar 2018, at 16:41, Jim Reid wrote:

> I think these may be needed for SIP, particularly roving (nameless) 
> clients. And quite possibly for P2P applications.

How could you use ACME to validate the IP address of a roving client or 
a P2P application that has no fixed IP address?

Having said that:

> which the server's address is known but not its name.

This seems like a reasonable use case.

>> If your list is longer than zero, are you willing to help Roland with 
>> a solution using DNS records for validation that has any chance of 
>> being usable?
>
> Yes, I’d be willing to work with Roland on at least finding and 
> documenting likely use cases. Are you? Whether we (or others) can then 
> come up with something that has any chance of being usable is another 
> matter.

Exactly. Given the difficulty of getting stable in-addr.arpa and 
ipv6.arpa records at all, being able to write a TXT record into them 
seems completely unstable. Thus, "temporarily put up a web server where 
you were going to put up the DNS (or other) server" seems the most 
likely to work reliably. If you have other ideas, that's great.

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Tue, 13 Mar 2018 01:31:41 +0000

> On 13 Mar 2018, at 00:07, Paul Hoffman <[email-masked]> wrote:
> 
> How could you use ACME to validate the IP address of a roving client or a P2P application that has no fixed IP address?

In pretty much the same way as ACME tokens would/could be used to validate clients that have (fixed) names.

Or perhaps these hypothetical IP-flavoured tokens contain a public key which could be used for opportunistic encryption with whatever’s at that IP address. Add hand-waving to taste.

At this very eary stage, questions shouldn’t about how these hypothericals will get implemented. I’m just giving some possible examples of use cases other than webbery, like you asked for. They might be bad or stupid use cases. Or turn out to be pointless. Or unworkable. Or all of the above. For now they’re just things that might be on the list that you, me and Roland eventually produce.

---

From: Tony Finch <[email-masked]>
Date: Tue, 13 Mar 2018 14:55:10 +0000

Roland Bracewell Shoemaker <[email-masked]> wrote:
>
> 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

IMO it's fine from the protocol point of view to put TXT records in the
reverse DNS. (Remember to allow for following CNAMEs and other forms of
classless delegation.)

From the operational point of view, you're going to bump into a lot of
annoying road blocks: undelegated reverse DNS, provisioning systems that
only allow for PTR, etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
North Utsire, South Utsire: Variable 3 or 4, becoming southeasterly 5 or 6.
Moderate or rough. Fog patches. Good, occasionally very poor.

---

From: Joe Abley <[email-masked]>
Date: Tue, 13 Mar 2018 11:16:56 -0400

> 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 n…

I think that if Tony can be [email-masked], surely I can be [email-masked].

A zone is a zone. ARPA is only special by convention, not by protocol.

Joe

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 13 Mar 2018 11:18:51 -0400

On Tue, Mar 13, 2018 at 11:16 AM, Joe Abley <[email-masked]>
wrote:

> 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?
>
> ^^ Joe spoke the truth

Olafur

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Mar 2018 11:22:24 -0400

On Mar 13, 2018, at 11:16 AM, Joe Abley <[email-masked]> wrote:
> 
> I think that if Tony can be [email-masked] <mailto:[email-masked]>, surely I can be [email-masked] <mailto:[email-masked]>.
> 

Yup.

Thinking through the threat model here, when would this even work?   It would certainly work in principle for stable servers that have reverse delegations.   For servers that move around a lot, it seems like a really crappy solution.   Why do you trust a server that's moving around a lot?   Presumably because you've already established trust with it OOB.   So why do you need ACME in this case?

For the case of a server that's not moving around a lot, why is it useful?   How did your resolver know to contact that particular server?

I don't see anything in the document describing the motivating use case.   Did I miss that from some other document?

---

From: Joe Abley <[email-masked]>
Date: Tue, 13 Mar 2018 11:27:00 -0400

On 13 Mar 2018, at 11:22, Ted Lemon <[email-masked]> wrote:

> Thinking through the threat model here, when would this even work?

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.

Joe

---

From: Joe Abley <[email-masked]>
Date: Tue, 13 Mar 2018 11:29:20 -0400

> annoying road blocks: undelegated reverse DNS, provisioning systems that

Data point: Google's MXes evidently have no interest accepting mail from me directly when I use this e-mail address :-)

Joe

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Mar 2018 11:38:46 -0400

> 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 pop…

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.

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 13 Mar 2018 12:59:07 -0300

> A zone is a zone. ARPA is only special by convention, not by protocol.

Sure. Extra data, people in less stocked address networks have being
following BCP20 with the extra trick of putting delegations and
associated glue inside the same in-addr.arpa zone for ages.

Fred

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Mar 2018 17:31:30 +0100

On Tue, Mar 13, 2018 at 02:55:10PM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 42 lines which said:

> From the operational point of view, you're going to bump into a lot
> of annoying road blocks: undelegated reverse DNS, provisioning
> systems that only allow for PTR, etc.

I fully agree.

Playing with DNSDB, one can find funny TXT records in in-addr.arpa:

5.92.111.2.in-addr.arpa
118.41.193.in-addr.arpa
111.28.34.193.in-addr.arpa (I like this one)
168.41.193.in-addr.arpa (Joe will love this one)