Subject: Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information

From: 神明達哉 <[email-masked]>
Date: Mon, 1 Jul 2019 16:11:14 -0700

At Sat, 29 Jun 2019 22:55:07 +0000,
Paul Hoffman <[email-masked]> wrote:

> > - I think the RESINFO RDATA specification (at least its wire format,
> >   and preferably also the presentation format) should be more clearly
> >   specified.  At least to me it was not very clear, and I'm afraid
> >   this can lead to interoperability problems.
>
> It is a JSON object. What beyond that description would help?

For example, if it can be a part of a standard zone file, what's the
expected presentation format?  Is it a la TXT character string (but
there's no length limitation) or something special?  How do we handle
non-ascii characters?

Also, how do we compare RESINFO RDATAs?  Should they be compared as
opaque binary, or should two semantically identical JSON objects
considered equal as RESINFO RDATA too (even if, for example, they are
different regarding white spaces)?

> > - The last sentence of Section 2 doesn't make sense to me:
> >
> >    they only need code to handle the RESINFO RRtype that is not in
> >    <reverse-ip>.{in-addr,ip6}.arpa/IN or a subdomain of <reverse-
> >    ip>.{in-addr,ip6}.arpa/IN .
> >
> >   Should it actually be "that is in" instead of "that is not in"?  If
> >   it's really "not in", I don't know how to interpret this in this
> >   context...
>
> The whole sentence is confusing, and we can remove it. Thus, that whole
paragraph can go away.

It may depend on the original intent of the NODATA/NXDOMAIN
restriction, but I'm personally fine with that.

--
JINMEI, Tatuya

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Jul 2019 00:40:00 +0000

On Jun 30, 2019, at 1:08 AM, Ralf Weber <[email-masked]> wrote:
> On 30 Jun 2019, at 1:01, Paul Hoffman wrote:
>>> - The draft offers two methods of retrieving the object but says nothing about which is mandatory (Me being a lazy DNS geek will certainly not put a web server on my DNS server so won’t implement 3). Will it still work? Why?
>> 
>> Neither is mandatory: both are optional. That is, we cannot force a resolver to give information about itself, nor can we force it to do something abnormal for a resolver (be authoritative for a new type of query or run a web server).
> Sure you can not, but as we have seen with RFC8484 deplopyment where browser vendors can say, oh if you don’t speak this (our language) we will just go around you and talk to someone else. I want to avoid that situation in discovery. So we have to give the client of such a protocol clear guidance on what to do. IMHO try both ways and only if none work go back to your fallback scenario. That is missing in the draft.

I don't see the parallel with RFC 8484. We cannot force resolver vendors to care enough about announcing information about themselves to use either protocol. And we certainly cannot tell applications how to search for information. We can, however, offer options that either can use.

>> The name doesn't need to be in the config of the DNS part of the resolver: it would only appear in the TLS part, just as it does in every web server that supports TLS.
> That does make no sense. Where does a client of discovery get the name from? All stub resolvers I know only have the IP configured and not a name. Can you explain where the name for such a call would come from?

Current DHCP only offers information on resolvers by IP address, but that doesn't mean that no future version of resolver discover would not, particularly in situations where an OS or application already has one resolver and wants to get to a different one. That is, there is no reason not to add this as a potential for the future.

>>> - The biggest issue IMHO are RFC1918 and IPv6 link local addresses as these are mostly used in homes for DNS resolver addresses. This means that the CPE - who usually is a DNS Forwarder has to answer (and understand) this query and either forward or answer by himself. DNS Proxies might not implement RFC3597.
>> 
>> If a resolver of any type can't be configured to give the information here, it just won't.
> Again the problem are the consequences when it doesn’t. Which might happen because even though the ISP resolver has configured the RESINFO record it simply might not get the query if it is ignored by the proxy on the CPE the customer has bought, because of type.

Are there words we could add to make this clearer? I ask because I still don't see how your concern can be dealt with in the protocol.

>>> Should there be a fallback (TXT)?
>> 
>> I'm not sure how that would help if it can't be configured due to address issues.
> DNS proxies can forward stuff and you could put wildcard answers on the link local/RFC1918 addresses. So you could actually make it work. But the likelihood of being able to forward TXT are bigger then the likelihood of being able to forward RESINFO, thus my question for fallback.

This surprises me. There are forwarders that only forward requests and responses based on the RRtype?

> In general I don’t like the idea of traversing the reverse tree for that as we can not validate it in a lot of use cases anyway and the information we want is rather static and does not necessarily appear in the global DNS as it is first line resolver specific.

Understood, but people objected earlier to our use of a special-use domain name that could not have DNSSEC signing. If we want DNSSEC signing, we have to use the DNS reverse tree for the names, even though only a tiny percent of that tree will be signed.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Jul 2019 00:42:46 +0000

> there's no length limitation) or something special?  How do we handle

Ah, I had not considered the presentation format. We'll add something about that in the next draft.

> different regarding white spaces)?

As opaque binary, definitely. JSON has so many ways of doing character escaping, it would be unlikely to make a completely correct JSON text comparator. We'll add that in the next draft as well.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Wed, 3 Jul 2019 19:13:40 -0700

Hi Paul,

On Jul 3, 2019, at 20:40, Paul Hoffman <[email-masked]> wrote:

> If we want DNSSEC signing, we have to use the DNS reverse tree for the names, even though only a tiny percent of that tree will be signed.

Aside from those parts of the in-addr.arpa and ip6.arpa domains that
correspond to special-use and unassigned addresses, I don't believe
there's any operational or protocol reasons that both domains couldn't
be completely signed today. I'm aware that is not the case, but you
sound oddly definitive in your statement above.

Can you say more about what you mean? Is it a prediction, or a
measurement, or a mixture, or something else?

Joe

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 04 Jul 2019 15:18:29 +0200

Moin!

On 4 Jul 2019, at 2:40, Paul Hoffman wrote:
> I don't see the parallel with RFC 8484. We cannot force resolver 
> vendors to care enough about announcing information about themselves 
> to use either protocol. And we certainly cannot tell applications how 
> to search for information. We can, however, offer options that either 
> can use.
Of course we can. If we define a discovery protocol for secure DNS we 
can define what a discovery client has to do. If we don’t do this it 
will cause problems. Say if from the draft resolver vendor N implements 
section 2 and browser vendor M implements section 3, both have 
implemented the protocol still it won’t work together.

> Current DHCP only offers information on resolvers by IP address, but 
> that doesn't mean that no future version of resolver discover would 
> not, particularly in situations where an OS or application already has 
> one resolver and wants to get to a different one. That is, there is no 
> reason not to add this as a potential for the future.
Hmm a name as entry point for a name resolution protocol - ok maybe some 
future engineers come up with something but until we should say that 
current protocols don’t support it explicit and not implicit as it 
will confuse people.

>> Again the problem are the consequences when it doesn’t. Which might 
>> happen because even though the ISP resolver has configured the 
>> RESINFO record it simply might not get the query if it is ignored by 
>> the proxy on the CPE the customer has bought, because of type.
>
> Are there words we could add to make this clearer? I ask because I 
> still don't see how your concern can be dealt with in the protocol.
The fallback to TXT or some other way to get to the resolver IP to ask.

>> DNS proxies can forward stuff and you could put wildcard answers on 
>> the link local/RFC1918 addresses. So you could actually make it work. 
>> But the likelihood of being able to forward TXT are bigger then the 
>> likelihood of being able to forward RESINFO, thus my question for 
>> fallback.
>
Well I saw this in the early days of DNSSEC deployment where a proxy 
(which is a forwarder, but dumber) did forward A, AAAA, MX, TXT, NS, 
etc. but not DNSKEY or any query type he did know nothing about. As we 
are defining a new query type this problem might surface again, thus the 
proposed fallback to txt or some other mechanism to work around the CPE 
at the customer site. I liked the idea of the earlier draft where there 
was a special name to get to the IP of the resolver.

> Understood, but people objected earlier to our use of a special-use 
> domain name that could not have DNSSEC signing. If we want DNSSEC 
> signing, we have to use the DNS reverse tree for the names, even 
> though only a tiny percent of that tree will be signed.
Well DNSSEC signing might work with the proper resolver signing reverse 
for RFC1918 which is a very common case will not work.

SO long
-Ralf
—--
Ralf Weber

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Jul 2019 14:34:25 +0000

On Jul 3, 2019, at 7:13 PM, Joe Abley <[email-masked]> wrote:
> be completely signed today.

Fully agree.

> I'm aware that is not the case, but you

I guess I left off the "unfortunately, I predict" part.

> measurement, or a mixture, or something else?

A prediction based on current measurements. Seriously, I'd love to be shown to be wrong in the future.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 4 Jul 2019 10:46:50 -0400 (EDT)

> A prediction based on current measurements. Seriously, I'd love to be shown to be wrong in the future.

We needed this for the freeswan project 25 years ago and it hasn't
happened. Additionally, classless reverse delegation is even harder
to get from ISPs if you don't have a full a /24, and I'm not even
talking about signing your classless reverse delegation.

Solution for endusers that need a DNSSEC signed reverse will not see
deployment. I'd be happ to be wrong and that this will cause it to
happen more than for our freeswan project, but I wouldn't bet on it.

Paul

---

From: tirumal reddy <[email-masked]>
Date: Tue, 9 Jul 2019 16:16:44 +0530

Hi Paul,

My comments below:

1) Unless a DNS request for <reverse-ip>.{in-addr,ip6}.arpa/IN/RESINFO,
   or a subdomain, as described in Section 2 is sent over DNS-over-TLS
   (DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484], or unless the
   <reverse-ip>.{in-addr,ip6}.arpa zone is signed with DNSSEC, the
   response is susceptible to forgery.

Comment> If the stub resolver is already using DoH with the recursive
resolver, why does it have to determine the URI template of the DoH server?

2) DHCP clients typically have no secure and trusted relationships to DHCP
servers, how will the client know it is communicating with the recursive
resolver hosted in the attached network ?

3)
   In the future, DHCP and/or DCHPv6 and/or RA may have options that
   allow the configuration to contain the domain name of a resolver.  If
   so, this can be used for matching the domain name in the TLS
   certificate.

Comment> Same comment as above, Please see
https://tools.ietf.org/html/rfc8310#section-7.3.1

4) Any specific reason for picking I-JSON ?

5) The resolver information can also be provided in the server certificate
itself, for example see
https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-04#section-10.1.
The
pros and cons of both approaches need to be discussed in the WG.

Cheers,
-Tiru

On Fri, 28 Jun 2019 at 00:14, Paul Hoffman <[email-masked]> wrote:

> Greetings. We have again updated draft-sah-resolver-information based on
> comments from this mailing list. We think that this is ready for adoption
> by the WG so that the initial use of the protocol (to be able to determine
> the URI template of the DoH server preferred by your current resolver) can
> move forward as well.
>
> --Paul Hoffman
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : DNS Resolver Information Self-publication
>         Authors         : Puneet Sood
>                           Roy Arends
>                           Paul Hoffman
>         Filename        : draft-sah-resolver-information-02.txt
>         Pages           : 9
>         Date            : 2019-06-27
>
> Abstract:
>    This document describes methods for DNS resolvers to self-publish
>    information about themselves, such as whether they perform DNSSEC
>    validation or are available over transports other than what is
>    defined in RFC 1035.  The information is returned as a JSON object.
>    The names in this object are defined in an IANA registry that allows
>    for light-weight registration.  Applications and operating systems
>    can use the methods defined here to get the information from
>    resolvers in order to make choices about how to send future queries
>    to those resolvers.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-sah-resolver-information/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-sah-resolver-information-02
> https://datatracker.ietf.org/doc/html/draft-sah-resolver-information-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-sah-resolver-information-02
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 11 Jul 2019 00:25:03 +0000

On Jul 9, 2019, at 3:46 AM, tirumal reddy <[email-masked]> wrote:
> Comment> If the stub resolver is already using DoH with the recursive resolver, why does it have to determine the URI template of the DoH server?

One example is that the stub or browser may want to change DoH servers, such as if it has discovered one that has a better security policy.

> 2) DHCP clients typically have no secure and trusted relationships to DHCP servers, how will the client know it is communicating with the recursive resolver hosted in the attached network ?

It will not. This has always been the problem with DHCP, and efforts to make DHCP authenticated have not borne fruti.

> Comment> Same comment as above, Please see https://tools.ietf.org/html/rfc8310#section-7.3.1 [tools.ietf.org]

That document does not preclude future configuration options. I don't see any reason for this spec to do so.

> 4) Any specific reason for picking I-JSON ?

Absolutely. I-JSON is more likely to be interoperable than plain JSON: that's why it exists. Given that the developers of the clients for this protocol will be different than the developers of the servers, greater interoperability should be an emphasis.

> 5) The resolver information can also be provided in the server certificate itself, for example see https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-04#section-10.1 [tools.ietf.org]. The pros and cons of both approaches need to be discussed in the WG.

Agree. If that document progresses, it will certainly have an effect on the protocol proposed here.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 11 Jul 2019 22:55:45 -0400 (EDT)

> One example is that the stub or browser may want to change DoH servers, such as if it has discovered one that has a better security policy.

I find the term "security policy", a bit unnerving here. A DNS server
is either secure (and tells the truth), or it is not secure (and tells
lies). There is no "better". Some people say lying is more "secure for the
user", but that can really only come from a pre-existing configuration,
not a random DNS server offered by your random local network.

I think the better term here is "privacy policy". We kind of assume
all DoH severs are "secure" (at least for their transport, see above)
but we feel we can trust some DoH servers more than others for privacy.

> It will not. This has always been the problem with DHCP, and efforts to make DHCP authenticated have not borne fruti.

And since the prime advantage of DoH is privacy, and you cannot
have privacy without an authenticated encrypted channel, using a
randomly announced third party DoH server gains you little (and surely
unmeasurable) privacy. Unless you already trust the DoH server announced,
but than you hardly need the DHCP announcement. Just setting up the
connection to the DoH servers you trust (and have certs/CA for) until
one works. If those fail, you might as well use UDP 53 to whatever DHCP
gave you.

>>    so, this can be used for matching the domain name in the TLS

As stated above, I see only very little use in this.

Paul

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 12 Jul 2019 10:36:00 +0200 (CEST)

> but we feel we can trust some DoH servers more than others for privacy.

No, it is really about security, but in a broader sense. Some resolvers will lie to you when you try to access a known malicious destination, e.g. a website which hosts malware or phishing, or, if "you" are a bot, your command and control server. This would be "insecure" by your definition above, but in reality it makes the whole Internet access experience more secure.

In this scenario, a "better" security policy by a resolver is one using a list of filtered destinations that is more precise, more timely updated, more localized, more tailored to your own needs (including the fact that some resolvers allow each individual user of the local network to choose a different filtering policy, or none at all).

So the user might indeed want to use a resolver that employs a better security policy, or even the resolver with which they have a contract to provide a specific security policy, which, in the case of ISPs, will usually be the one advertised by the local network.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 16 Jul 2019 16:34:41 -0400

On Sun, Jun 30, 2019 at 4:09 AM Ralf Weber <[email-masked]> wrote:

> DNS proxies can forward stuff and you could put wildcard answers on the
> link local/RFC1918 addresses. So you could actually make it work.

This is an interesting idea, but plenty of forwarders aren't on RFC 1918
addresses.  To work through forwarders and complex server deployments, I
think we would have to go even further, e.g. recommending that
participating resolvers respond to _all_ RESINFO queries, whether or not
the address matches their own.

If that doesn't seem appealing, I think we'd be better off reverting to the
"-00" draft's approach of using "resolver-info.arpa".  The change to
<rev-ip>.in-addr.arpa was made to enable secure validation of the resolver
info, in cases where the original IP address was delivered securely (i.e.
trusted DHCP).  For those use cases, I think we would be better off
defining a DHCP option to deliver the I-JSON blob over DHCP alongside the
IP address.

--Ben

---

From: tirumal reddy <[email-masked]>
Date: Wed, 17 Jul 2019 20:06:00 +0530

Hi Paul,

Please see inline

On Thu, 11 Jul 2019 at 05:55, Paul Hoffman <[email-masked]> wrote:

> One example is that the stub or browser may want to change DoH servers,
> such as if it has discovered one that has a better security policy.
>

Attackers can also host DoH servers and claim they have better security
policy, How will the stub resolver know the server is not lying ?

>
> > 2) DHCP clients typically have no secure and trusted relationships to
> DHCP servers, how will the client know it is communicating with the
> recursive resolver hosted in the attached network ?
>
> It will not. This has always been the problem with DHCP, and efforts to
> make DHCP authenticated have not borne fruti.
>

Yes, but how will the client know it is communicating with an attacker's
DoH server or not ?
In other words, if the client does not securely learn the IP address or
domain name of the resolver, the client could end-up retrieving the
attacker's resolver information.

> https://tools.ietf.org/html/rfc8310#section-7.3.1 [tools.ietf.org]
>

Discussing these future configuration options without solving the secure
bootstrapping problem is of little use to implementations and deployments.

> Absolutely. I-JSON is more likely to be interoperable than plain JSON:
> that's why it exists. Given that the developers of the clients for this
> protocol will be different than the developers of the servers, greater
> interoperability should be an emphasis.
>

JSON also provides interoperability, please see
https://tools.ietf.org/wg/jose/charters. My other question is why JSON and
not CBOR ?

Cheers,
-Tiru

>
> > 5) The resolver information can also be provided in the server
> certificate itself, for example see
> https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-04#section-10.1
> [tools.ietf.org]. The pros and cons of both approaches need to be
> discussed in the WG.
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Jul 2019 16:17:24 +0000

On Jul 17, 2019, at 7:36 AM, tirumal reddy <[email-masked]> wrote:
> Attackers can also host DoH servers and claim they have better security policy, How will the stub resolver know the server is not lying ?

The same way that they will authenticate any policy information. This is no different than any other policy choice, is it?

>> It will not. This has always been the problem with DHCP, and efforts to make DHCP authenticated have not borne fruit.
>> 
> Yes, but how will the client know it is communicating with an attacker's DoH server or not ?
> In other words, if the client does not securely learn the IP address or domain name of the resolver, the client could end-up retrieving the attacker's resolver information.

Are you saying that the only way for a client to learn policy information is from secure DHCP or secure RA? It seems like others here disagree with that, and want network administrators to be able to leverage the resolvers under their control to issue policy statements.

> Discussing these future configuration options without solving the secure bootstrapping problem is of little use to implementations and deployments.

Others seem to disagree with that statement.

> JSON also provides interoperability, please see https://tools.ietf.org/wg/jose/charters.

I-JSON was partially motivated by problems discovered in JOSE.

> My other question is why JSON and not CBOR ?

CBOR has no advantages in this use case, and JSON is easy to put into master files.

--Paul Hoffman

---

From: tirumal reddy <[email-masked]>
Date: Thu, 18 Jul 2019 15:17:26 +0530

Hi Paul,

Please see inline

On Wed, 17 Jul 2019 at 21:47, Paul Hoffman <[email-masked]> wrote:

> The same way that they will authenticate any policy information. This is
> no different than any other policy choice, is it?
>

No, I am not aware of any standard techniques used by endpoints and IoT
devices to authenticate the policy information provided by the network ?
If you are aware of such techniques, Please share.

> make DHCP authenticated have not borne fruit.
> >>
> Are you saying that the only way for a client to learn policy information
> is from secure DHCP or secure RA? It seems like others here disagree with
> that, and want network administrators to be able to leverage the resolvers
> under their control to issue policy statements.
>

I am not proposing to use Secure DHCP or secure RA. Consider a scenario
where an attacker also hosts a resolver and issues policy statements to
claim better security and privacy than the one provided the network
administrator. How will the client know the policy statement is issued by
the resolver deployed by the network administrators or by an attacker ?

> Others seem to disagree with that statement.

Sure, but I don't see any discussion in the draft explaining how the client
determines the future configuration options is coming from a trusted
source. If the source cannot be trusted, endpoint can be configured to use
a malicious resolver server compromising the endpoint security and privacy,
and the future configuration options is not helpful.

> https://tools.ietf.org/wg/jose/charters.
>

Okay.

> CBOR has no advantages in this use case, and JSON is easy to put into

CBOR has smaller message size compared to JSON and is faster to process
than JSON.

Cheers,
-Tiru