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

[Stephane Bortzmeyer]

On Tue, Mar 13, 2018 at 02:55:10PM +,
 Tony Finch  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)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Frederico A C Neves]

On Tue, Mar 13, 2018 at 11:16:56AM -0400, Joe Abley wrote:
> On 12 Mar 2018, at 11:58, Roland Bracewell Shoemaker  
> wrote:
> 
> > 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?
> 
> I think that if Tony can be d...@dotat.at, surely I can be 
> jab...@90.212.199.in-addr.arpa.
> 
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Mar 13, 2018, at 11:27 AM, Joe Abley  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.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 13 Mar 2018, at 10:55, Tony Finch  wrote:

> 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.

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


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 13 Mar 2018, at 11:22, Ted Lemon  wrote:

> On Mar 13, 2018, at 11:16 AM, Joe Abley  
> wrote:
> 
>> I think that if Tony can be d...@dotat.at, surely I can be 
>> jab...@90.212.199.in-addr.arpa.
>> 
>> A zone is a zone. ARPA is only special by convention, not by protocol.
> 
> Yup.
> 
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Mar 13, 2018, at 11:16 AM, Joe Abley  wrote:
> 
> I think that if Tony can be d...@dotat.at , surely I 
> can be jab...@90.212.199.in-addr.arpa .
> 
> A zone is a zone. ARPA is only special by convention, not by protocol.

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?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ólafur Guðmundsson]

On Tue, Mar 13, 2018 at 11:16 AM, Joe Abley 
wrote:

> On 12 Mar 2018, at 11:58, Roland Bracewell Shoemaker <
> rol...@letsencrypt.org> wrote:
>
> > 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?
>
> I think that if Tony can be d...@dotat.at, surely I can be
> jab...@90.212.199.in-addr.arpa.
>
> A zone is a zone. ARPA is only special by convention, not by protocol.
>
> ^^ Joe spoke the truth

Olafur
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 12 Mar 2018, at 11:58, Roland Bracewell Shoemaker  
wrote:

> 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?

I think that if Tony can be d...@dotat.at, surely I can be 
jab...@90.212.199.in-addr.arpa.

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


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Roland Bracewell Shoemaker  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
> technical reasons or we just being a bit too strict in our reading of
> 3172?

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.finchhttp://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.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

> On 13 Mar 2018, at 00:07, Paul Hoffman  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.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

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


On 12 Mar 2018, at 23:27, Paul Hoffman  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.


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:

On 12 Mar 2018, at 16:43, Paul Vixie wrote:

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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

On Monday, March 12, 2018 11:12:36 PM GMT Jim Reid wrote:
> > On 12 Mar 2018, at 17:37, Paul Hoffman  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... :-)

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

> On 12 Mar 2018, at 23:27, Paul Hoffman  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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

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


On 12 Mar 2018, at 17:37, Paul Hoffman  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

> On 12 Mar 2018, at 17:37, Paul Hoffman  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... :-)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Roland Bracewell Shoemaker]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Roland Bracewell Shoemaker]

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop