Subject: [DNSOP] Call for Adoption: draft-sah-resolver-information

From: Tim Wicinski <[email-masked]>
Date: Fri, 2 Aug 2019 11:04:05 -0400

This draft has come up and has had a lot of discussion.  Mostly
positive, some desiring more details on the information
that could be returned.  If the working group adopts the draft,
this can all be worked out.

This starts a Call for Adoption for draft-sah-resolver-information

The draft is available here:
https://datatracker.ietf.org/doc/draft-sah-resolver-information/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 16 August 2019

Thanks,
tim wicinski
DNSOP co-chair

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 03 Aug 2019 13:35:41 +1000

> This starts a Call for Adoption for draft-sah-resolver-information

I think that I might have said this before, but I don't think that asking an HTTP server about a DNS server is the right solution.  If this is information about the operation of a participant in the DNS protocol, then I think that this needs to use the DNS protocol. For connection-oriented interactions, having the information associated with a connection (and not a server identity) would be even better.

This also bakes in the notion that a DNS resolver is identified by IP address.  The domain name part is probably OK, but I don't know which trust anchors to use.  I think that the document is assuming that we'll use the Web PKI, but it doesn't say that (nor does RFC 8310, as far as I can tell).  If you can answer the question "why not DANE?" then you might start to understand my concerns here.

The RESINFO RRtype seems OK, but I have less confidence in my ability to assess that aspect of this.  The only thing that bothers me is the potential for 1.0.0.10.in-addr.arpa and friends to leak and ruin the protocol for everyone.  I realize that there are no good solutions here, but it would be good if there were a little more clarity on the constraints this group thought applied to the design.

The inventory thing is fairly irregular.  The names of fields are right there already, why insist on repeating them in an array?

With all that, I think that it would be premature to assume that this is the right direction.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 3 Aug 2019 14:37:36 +0000

> On Aug 2, 2019, at 8:35 PM, Martin Thomson <[email-masked]> wrote:
> 
> I think that I might have said this before, but I don't think that asking an HTTP server about a DNS server is the right solution.  

It is not "the" right solution, but it is one of them. That's why there is also a DNS-based solution in the same document.

> If this is information about the operation of a participant in the DNS protocol, then I think that this needs to use the DNS protocol.

Agree. See above.

> For connection-oriented interactions, having the information associated with a connection (and not a server identity) would be even better.

Not sure what you mean by "connection-oriented interactions". DNS is not connection-oriented at all.

> This also bakes in the notion that a DNS resolver is identified by IP address.  

Not at all: the resolver must have an IP address, but can also have a domain name. In the case of an application that is doing it's own stub resolution, the stub could use the OS's stub to get the address of the resolver's domain name. Such an application-based-stub could then use all of its own HTTPS-based security policies to get the resolver's information.

> The domain name part is probably OK, but I don't know which trust anchors to use.  I think that the document is assuming that we'll use the Web PKI, but it doesn't say that (nor does RFC 8310, as far as I can tell).

The TLS and HTTP2 documentes also don't say which trust anchors to use. :-)

> If you can answer the question "why not DANE?" then you might start to understand my concerns here.

Allowing the use of a domain name in an environment where DANE is used is exactly one intended use case.

> The RESINFO RRtype seems OK, but I have less confidence in my ability to assess that aspect of this.  The only thing that bothers me is the potential for 1.0.0.10.in-addr.arpa and friends to leak and ruin the protocol for everyone.  

Please say more here. Who do you think would be publishing at 10.0.0.1? 

> I realize that there are no good solutions here, but it would be good if there were a little more clarity on the constraints this group thought applied to the design.

Sure.

> The inventory thing is fairly irregular.  The names of fields are right there already, why insist on repeating them in an array?

The document says that the response does not need to include all the name-value pairs that a resolver knows. The use case is that someone might define a name-value pair that they only want to emit if asked for, such as if the data is large.

If the WG finds this to be too much of an edge case, we can certainly eliminate the inventory, but it feels to me that requiring that every response always contain every known name-value pair is onerous.

--Paul Hoffman

---

From: Rob Sayre <[email-masked]>
Date: Sat, 3 Aug 2019 19:15:14 -0700

> by DNSOP, and comments to the list, clearly stating your view.

I don't understand what this draft aims to standardize, and I don't think
it is suitable for adoption.

It might describe an interesting experiment in software, but I don't see
why the IETF should be involved.

thanks,
Rob

---

From: Paul Wouters <[email-masked]>
Date: Sun, 4 Aug 2019 20:04:22 -0400 (EDT)

On Fri, Aug 2, 2019 at 8:04 AM Tim Wicinski <[email-masked]> wrote:
> 
> The draft is available here: https://datatracker.ietf.org/doc/draft-sah-resolver-information/
> 

I'm okay with adopting it, but I do think some work needs to be done for
the document. One example is the sentence "acts as if it is delegated"
and then shows how to override a delegated answer.

It is also a little weird that the document starts a new registry,
and than fails to put in a single entry.

But the WG can work on those,

Paul

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 05 Aug 2019 11:00:55 +1000

On Sun, Aug 4, 2019, at 00:37, Paul Hoffman wrote:
> It is not "the" right solution, but it is one of them. That's why there 
> is also a DNS-based solution in the same document.

Let me be slightly more pointed then.  I think that documenting a solution that has one protocol speak for another would be a bad idea.  Even if there is a better way to do the same thing in a "better" way.
 
> not connection-oriented at all.

Neither is HTTP, but it uses connection-oriented interactions: TCP connections.  There is still a strong desire in HTTP to retain the stateless nature of the protocol, but we have cracked that open slightly.  Building some ability to talk directly to the next hop in a limited fashion, as we are now able to with HTTP/2, has some real benefits.
 
> Please say more here. Who do you think would be publishing at 10.0.0.1? 

A good proportion of the resolvers I talk to operate from 1918 space, how else would they advertise this information?  I don't care if they are merely proxies, and nor should it matter if they are.

The fact that they are proxies means that my ISP is likely going to be the one fielding RESINFO queries for 10.0.0.1 and friends.

> If the WG finds this to be too much of an edge case, we can certainly 
> eliminate the inventory, but it feels to me that requiring that every 
> response always contain every known name-value pair is onerous.

The sort of filtering you are contemplating isn't supported by the protocol you define.  It's also quite a bit more complicated to specify and build.  If there is a need for subdivision for performance reasons, which would have to be proven, there might be better ways to approach this.

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 05 Aug 2019 12:49:26 +0200

Moin!

> it is suitable for adoption.
It describes a protocol for a recursive resolver to publish information about
itself that supposedly applications can use to either connect to it with a
different protocol or display information to an enduser.

And while I agree with others (Paul Wouters, Martin Thomson) that the
document needs work I’d support adoption as I want to see that we work on
the problem of auto discovery of DoH servers which is one of the cases that
can be solved by this draft (when enhanced appropriately)

So long
-Ralf
—--
Ralf Weber

---

From: tirumal reddy <[email-masked]>
Date: Mon, 5 Aug 2019 16:37:47 +0530

I did not receive response to the attacks discussed in
https://mailarchive.ietf.org/arch/msg/dnsop/4ubj2D4bzxS1VTsZKzcNqBcWgtM.
Listing the attacks and comments for further discussion:

a) Attackers can also host DoH/DoT servers and claim they offer security
and privacy policies. How will the stub resolver know the recursive server
is not lying ?

b) How will the client know the policy statement is issued by a resolver
deployed by the network administrator or by an attacker ?

c) I don't see any discussion in the draft explaining how the client
determines the future DHCP configuration options are 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 future DHCP configuration options will not be helpful (DHCP clients
typically have no secure and trusted relationships to DHCP servers).

d) What type of DNS information is self-published ?

e) What type of decisions will the stub resolver make based on the features
advertised by the recursive resolver ?

f) What is the need for both new RRtype and new well-known URI ?

g) Why isn't the information the resolver will publish discussed in this
document itself ?

h) An on-path attacker can modify the response to return NXDOMAIN response.
How is this attack prevented ?
    Looks like DNSSEC validating client is mandatory to detect fake
NXDOMAIN response.

i)  If the server certificate cannot be validated,  why will the client trust
the resolver information provided by server whose identify cannot be
validated ?

The draft does not look ready for adoption.

Cheers,
-Tiru

On Fri, 2 Aug 2019 at 20:34, Tim Wicinski <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: tirumal reddy <[email-masked]>
Date: Mon, 5 Aug 2019 16:41:55 +0530

> can be solved by this draft (when enhanced appropriately)

Auto discovery of DoT/DoH servers is an critical use case (several
discussions in ADD mailing list), it would be useful to first enhance the
draft to explain how this problem will be solved, and then ask for WG
adoption.

Cheers,
-Tiru

---

From: Joe Abley <[email-masked]>
Date: Mon, 5 Aug 2019 08:52:28 -0400

> Let me be slightly more pointed then.  I think that documenting a solution that has one protocol speak for another would be a bad idea.  Even if there is a better way to do the same thing in a "bet…

and

> The fact that they are proxies means that my ISP is likely going to be the one fielding RESINFO queries for 10.0.0.1 and friends.

together also trigger discomfort for me. DNS and HTTP requests might generally follow the same gradient as far as network address translation goes (escaping to ever-shallower NAT domains) but it's worth remembering that the gateways between the layers are not always just gateways at the IP layer; some are ALGs. The addresses that services are reachable at can can change between layers, as (in general) do the addresses used for proxy requests in the case of ALGs.

I'm concerned about the cases where:

(a) the data enclosed within a RESINFO response includes embedded IP addresses that may not match the addresses that correspond to the resolver service as viewed from another addressing domain, and

(b) the potential for HTTPS and DNS ALGs to further confuse matters as the system generating the RESINFO response for one retrieval protocol might not be the same as for the other.

I realise it's tempting to imagine that HTTPS is not subject to explicit or implicit handling by ALGs; however, anecdotally at least, SSL-stripping (e.g. with jurisdiction-specific trust anchors installed on clients) is on the rise and not just in enterprise networks. I've also seen networks where traffic is routed by policy in different directions according to transport-layer addresses, e.g. for reasons of available capacity or latency.

So I echo the concern about having one protocol speaking for another. I haven't quite got my head around what I think about RESINFO in general but this particular aspect seems like a more general weakness that is worth highlighting.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Aug 2019 14:26:26 +0000

Thank you for your detailed list 

On Aug 5, 2019, at 4:07 AM, tirumal reddy <[email-masked]> wrote:
> 
> I did not receive response to the attacks discussed in https://mailarchive.ietf.org/arch/msg/dnsop/4ubj2D4bzxS1VTsZKzcNqBcWgtM. 

To be clear, most of what you have below are not "attacks" at all.

> a) Attackers can also host DoH/DoT servers and claim they offer security and privacy policies. How will the stub resolver know the recursive server is not lying ?

The same way it can "know" that a web site it is going to follows that site's claims of security and privacy policies. That is: it cannot without help from trusted third parties. A resolver's claims inherently can be no different. This can be clarified in the draft.

> b) How will the client know the policy statement is issued by a resolver deployed by the network administrator or by an attacker ?

See above. This is barely different than the web model, if at all.

> c) I don't see any discussion in the draft explaining how the client determines the future DHCP configuration options are coming from a trusted
> source.

For the DNS method, it can use DNSSEC validation. For the HTTPS method, it can use normal TLS authentication. This can be clarified in the draft.

> If the source cannot be trusted, endpoint can be configured to use a malicious resolver server compromising the endpoint security and privacy,
> and future DHCP configuration options will not be helpful (DHCP clients typically have no secure and trusted relationships to DHCP servers).

Are you saying here that, because there is no typically-trusted way to get this information from DHCP, there should be no way to get it from the DNS either? If so, that seems like a harsh restriction.

> d) What type of DNS information is self-published ?

The draft clearly says that a resolver can self-publish any information it wants, so I don't understand the question.

> e) What type of decisions will the stub resolver make based on the features advertised by the recursive resolver ?

Whichever decision it wants. This is true for any protocol, yes?

> f) What is the need for both new RRtype and new well-known URI ?

As I said earlier in the thread, it is not a "need".

Some clients who want the information will want to use HTTPS because that's what they already do (such as applications with DoH clients); there is no need to force them to also have DNS transport stacks just to get the information. 

Some clients who want the information will want to use DNS because that's what they already do (such as stub resolvers); there is no need to force them to also have HTTPS transport stacks just to get the information.

> g) Why isn't the information the resolver will publish discussed in this document itself ?

This is the same as asking "why isn't every DHCP option defined in the main DHCP protocol specification". We cannot know all the kinds of information that a resolver will want to publish. Different resolver operators have told me that, if this is adopted, they will suggest types of information they want stubs to know about them. There is no reason to restrict them in that, I believe.

> h) An on-path attacker can modify the response to return NXDOMAIN response. How is this attack prevented ?
>     Looks like DNSSEC validating client is mandatory to detect fake NXDOMAIN response.

Yes, exactly. If you have a better suggestion, that would be great. 

> i)  If the server certificate cannot be validated,  why will the client trust the resolver information provided by server whose identify cannot be validated ?

That's up to a client's policy for the specific information they receive. Again, this is no different than DHCP. The fact that few DHCP clients actually use DHCP authentication hasn't stopped the world from using it widely.

> The draft does not look ready for adoption.

Given the above, and given that the WG would be able to change any part of the draft it wants, do you still feel that way? Or do you feel that there is no need at all for a resolver to be able to announce its features? 

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Aug 2019 14:45:26 +0000

> (b) the potential for HTTPS and DNS ALGs to further confuse matters as the system generating the RESINFO response for one retrieval protocol might not be the same as for the other.

Both are fair points. But, having said that, which single transport for the resolver information would you pick? DNS is clearly more "native" to the resolver itself, but many people objected to the fact that it is unlikely to be authenticated due to lack of deployment of DNSSEC down the reverse tree, and significant lack of deployment of validating stubs. HTTPS is clearly easier to authenticate with trusted CAs or DANE (for those few stubs that do validate), 

> I realise it's tempting to imagine that HTTPS is not subject to explicit or implicit handling by ALGs; however, anecdotally at least, SSL-stripping (e.g. with jurisdiction-specific trust anchors in…

Yep. The real question is whether we react to that by not using HTTPS at all, or use it anyway because it is more likely to get authentic answers to the client than DNSSEC is.

> So I echo the concern about having one protocol speaking for another. I haven't quite got my head around what I think about RESINFO in general but this particular aspect seems like a more general w…

We should definitely add this discussion to the draft if the WG adopts it. 

--Paul Hoffman

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 05 Aug 2019 08:58:01 -0600

While there is definitely a lot of work needed, this seems to be getting
substantive interest in the draft, so I'd support the WG adopting this
draft.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 5 Aug 2019 11:20:58 -0400

I support adoption, but I think we should consider a substantial
simplification of the design, focusing on a consensus core of basic
functionality.

I would propose removing all mention of HTTP, JSON, and reverse-IP.
Instead, we could just have a fixed special-purpose name (as in -00), with
an RRTYPE for each kind of info we intend to publish there.

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 05 Aug 2019 17:34:06 +0200

Moin!

On 5 Aug 2019, at 16:26, Paul Hoffman wrote:
> Some clients who want the information will want to use HTTPS because 
> that's what they already do (such as applications with DoH clients); 
> there is no need to force them to also have DNS transport stacks just 
> to get the information.
>
> Some clients who want the information will want to use DNS because 
> that's what they already do (such as stub resolvers); there is no need 
> to force them to also have HTTPS transport stacks just to get the 
> information.
This will not work as pointed out before. We either have to make 
publication (server side) of both protocols mandatory (which I don’t 
think is  good idea as I don’t want to run a HTTPs server at my DNS 
server) or we have to make the clients asking for both protocols 
mandatory. Having both sides decide on what they do will not create 
interoperable solutions.

So long
-Ralf
——-
Ralf Weber

---

From: Brian Dickson <[email-masked]>
Date: Mon, 5 Aug 2019 10:43:00 -0700

+1 to everything Joe wrote below. (There should be an automatic +1 to
things Joe writes.)

I'd like to suggest an approach to the issues of DNS forwarders + NATs of
varying depth/scope, but I think there may be some extra protocol work in
order to address these problems.

Also, I think there would be additional value in that extra work, in the
form of a "DNS traceroute" that would be possible.

Here are two conundrums:

   - Forwarding:
      - The server side of a DNS resolver (or forwarder) cannot determine
      if the client is a vanilla host (or stub or whatever), or a forwarder.
      - The client side of a DNS resolver (or forwarder) cannot determine
      if the server it is talking to is a full resolver or merely a forwarder.
      - Corollary: a forwarder cannot determine whether it is the only
      forwarder in a resolution path
   - EDNS:
      - EDNS is hop-by-hop
      - Thus, EDNS does not facilitate new EDNS records that might allow a
      client to pass stuff to the eventual resolver, or vice versa

There are two things, which combined, would get around this issue:

   - A way to pass an EDNS type to discover the identifier of every server
   (including forwarders) in a resolution chain
      - E.g. a transitive EDNS Type, that would have no entries on the
      query, but would include an ordered list of identities in the response
   - A way to target a DNS query at a specific identified forwarder/resolver
      - E.g. a transitive EDNS Type, indicating that only the
      forwarder/resolver with the specified ID should answer, and otherwise the
      query should be passed "upwards"

Use of these two hypothetical mechanisms would facilitate this RESINFO
draft (and do so within DNS itself).

It's too bad that the original spec for EDNS didn't include a bit in the
Type field for "transitive", the way that BGP attributes did. (Doing that
allows "unknown" types to be passed or dropped based solely on that bit.)

I realize that "transitive" only has any meaning in the forwarder context,
since recursive-authoritative is technically unrelated to
client-(forwarder*)-recursive.

I'm not sure it would be feasible at this point to propose fixing the
exclusively hop-by-hop nature of EDNS. However, I think there will always
be value and need for this, so perhaps doing it sooner would be less
painful.

Thoughts?

Brian

On Mon, Aug 5, 2019 at 5:53 AM Joe Abley <[email-masked]> wrote:

> >>> I think that I might have said this before, but I don't think that
> asking an HTTP server about a DNS server is the right solution.
> >>
> > Let me be slightly more pointed then.  I think that documenting a
> solution that has one protocol speak for another would be a bad idea.  Even
> if there is a better way to do the same thing in a "better" way.
>
> and
>
> >>> The RESINFO RRtype seems OK, but I have less confidence in my ability
> to assess that aspect of this.  The only thing that bothers me is the
> potential for 1.0.0.10.in-addr.arpa and friends to leak and ruin the
> protocol for everyone.
> >>
> > A good proportion of the resolvers I talk to operate from 1918 space,
> how else would they advertise this information?  I don't care if they are
> merely proxies, and nor should it matter if they are.
> >
> > The fact that they are proxies means that my ISP is likely going to be
> the one fielding RESINFO queries for 10.0.0.1 and friends.
>
> together also trigger discomfort for me. DNS and HTTP requests might
> generally follow the same gradient as far as network address translation
> goes (escaping to ever-shallower NAT domains) but it's worth remembering
> that the gateways between the layers are not always just gateways at the IP
> layer; some are ALGs. The addresses that services are reachable at can can
> change between layers, as (in general) do the addresses used for proxy
> requests in the case of ALGs.
>
> (a) the data enclosed within a RESINFO response includes embedded IP
> addresses that may not match the addresses that correspond to the resolver
> service as viewed from another addressing domain, and
>
> (b) the potential for HTTPS and DNS ALGs to further confuse matters as the
> system generating the RESINFO response for one retrieval protocol might not
> be the same as for the other.
>
> I realise it's tempting to imagine that HTTPS is not subject to explicit
> or implicit handling by ALGs; however, anecdotally at least, SSL-stripping
> (e.g. with jurisdiction-specific trust anchors installed on clients) is on
> the rise and not just in enterprise networks. I've also seen networks where
> traffic is routed by policy in different directions according to
> transport-layer addresses, e.g. for reasons of available capacity or
> latency.
>
> So I echo the concern about having one protocol speaking for another. I
> haven't quite got my head around what I think about RESINFO in general but
> this particular aspect seems like a more general weakness that is worth
> highlighting.
>
>
> Joe

---

From: "John Levine" <[email-masked]>
Date: 6 Aug 2019 01:30:33 -0400

>simplification of the design, focusing on a consensus core of basic

Agreed.  While I understand the motivation for this draft, the more I
look at it the less I understand the security model.  Like Joe I don't
understand the implications of the assumption that http and DNS
servers on the IP address are under the same management, or will
return consistent information.  

I also don't understand how this relates to DNSSEC, since the RESINFO
results are likely to be synthesized in the cache and are unlikely to
be signed.  To some extent DoH and DoT can mitigate MITM attacks since
their SSL certs may be able to tell you who you're talking to, but I
don't understand the downgrade and other attacks against whatever
security the certs provide.

R's,
John

---

From: tirumal reddy <[email-masked]>
Date: Tue, 6 Aug 2019 13:34:14 +0530

Hi Paul,

Please see inline

> To be clear, most of what you have below are not "attacks" at all.

Please explain why you think these are not "attacks" at all ?

> The same way it can "know" that a web site it is going to follows that
> site's claims of security and privacy policies. That is: it cannot without
> help from trusted third parties. A resolver's claims inherently can be no
> different. This can be clarified in the draft.
>

An user visiting a web site is different from an endpoint discovering a
network provided DoH/DoT server. Both good and back actors can advertise
DoH/DoT servers with the same security and privacy policies. The attacker
can also potentially block the discovery of good DoH/DoT server.

The above attacks are different from an user visiting www.google.com and
the browser rejecting the spoofed certificate from an MiTM.

How will the user/endpoint distinguish between advertised good and
malicious DoH/DoT servers  ?

> See above. This is barely different than the web model, if at all.

No, this is not the same as a web model. Attacker can host a malicious
domain, deploy DoH/DoT servers and get the server certificate signed by a
CA (it can be automated with ACME and is free of cost with letsencrypt).

> For the DNS method, it can use DNSSEC validation. For the HTTPS method, it
> can use normal TLS authentication. This can be clarified in the draft.
>

No, my comment is how will the client determine the future DHCP
configuration options are coming from a trusted source. TLS authentication
and DNSSEC validation will also work for malicious DoH/DoT servers.

>
> > If the source cannot be trusted, endpoint can be configured to use a
> malicious resolver server compromising the endpoint security and privacy,
> Are you saying here that, because there is no typically-trusted way to get
> this information from DHCP, there should be no way to get it from the DNS
> either? If so, that seems like a harsh restriction.
>

If DHCP response can be spoofed, the endpoint has no way to know the DNS
response is coming from a trusted source even with DNSSEC and TLS
validation.

Consider the following scenario:

The network to which the endpoint attached uses OpenDNS to block access to
malicious domains. The attacker spoofs the DHCP response to send
Google DoH/DOT server instead of OpenDNS. Assuming Google does not block
access to malicious domains, the attack is successful.
Note that DNSSEC and TLS server certificate validations will not prevent
the attack.

> The draft clearly says that a resolver can self-publish any information it
> wants, so I don't understand the question.
>

The question is what is the information and what is its use to the
endpoint. In other words, why should a stub resolver implement this
specification and what problems will it solve to the end user ?

>
> > e) What type of decisions will the stub resolver make based on the
> features advertised by the recursive resolver ?
>

No, the decisions may have privacy and security implications.

> that's what they already do (such as applications with DoH clients); there
> is no need to force them to also have DNS transport stacks just to get the
> information.
>
> Some clients who want the information will want to use DNS because that's
> what they already do (such as stub resolvers); there is no need to force
> them to also have HTTPS transport stacks just to get the information.
>

> This is the same as asking "why isn't every DHCP option defined in the
> main DHCP protocol specification". We cannot know all the kinds of
> information that a resolver will want to publish. Different resolver
> operators have told me that, if this is adopted, they will suggest types of
> information they want stubs to know about them. There is no reason to
> restrict them in that, I believe.
>

DHCP discusses several options (see
https://tools.ietf.org/html/rfc3315#section-22) and discusses scope for
future options in separate documents. This draft does not even specify any
details on the information the resolver will publish.

> Yes, exactly. If you have a better suggestion, that would be great.

If DNSSEC is mandatory to implement by the endpoint, it should be specified
in the document. Please note  neither https://tools.ietf.org/html/rfc8310
 nor https://tools.ietf.org/html/rfc8484 mandate the use of DNSSEC.

>
> > i)  If the server certificate cannot be validated,  why will the client
> trust the resolver information provided by server whose identify cannot be
> validated ?
>
> That's up to a client's policy for the specific information they receive.
> Again, this is no different than DHCP.

I don't see any such client policy mentioned in
https://tools.ietf.org/html/rfc8484. Are you aware of any browsers that
ignore server certificate validation
and why would the browser ignore the results of server certificate
validation ?

> The fact that few DHCP clients actually use DHCP authentication hasn't
> stopped the world from using it widely.
>

And the world is moving away from clear text HTTP to use HTTPS. Ignoring
the server certificate validation will compromise the endpoint security and
privacy, and needs strong justification.

> Given the above, and given that the WG would be able to change any part of
> the draft it wants, do you still feel that way?

Yes, the draft look premature for adoption. As you already know, the
outcome of this work will impact DPRIVE, DoH and the discussions in ADD
mailing list. You may want to inform them about this draft, and seek
feedback.

> Or do you feel that there is no need at all for a resolver to be able to
> announce its features?
>

No.

Cheers,
-Tiru

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 16 Aug 2019 07:43:07 -0400

All

The Call for Adoption for draft-sah-resolver-information has ended, and
there seems to be strong consensus.
The consensus is "Let's adopt this document, but let's do more work on the
details".  The chairs here this quite
strongly.

We'll adopt the document and if the working group should be able to work on
addressing all issues.

Thanks for the comments.

Tim

On Tue, Aug 6, 2019 at 4:05 AM tirumal reddy <[email-masked]> wrote:

> Hi Paul,
>
> Please see inline
>
> On Mon, 5 Aug 2019 at 19:56, Paul Hoffman <paul.hoffman@icann..org
> <[email-masked]>> wrote:
>
>> To be clear, most of what you have below are not "attacks" at all..
>>
>
>> > a) Attackers can also host DoH/DoT servers and claim they offer
>> security and privacy policies. How will the stub resolver know the
>> recursive server is not lying ?
>>
> DoH/DoT servers with the same security and privacy policies.. The attacker
>> > b) How will the client know the policy statement is issued by a
>> resolver deployed by the network administrator or by an attacker ?
>>
>> For the DNS method, it can use DNSSEC validation. For the HTTPS method,
>> it can use normal TLS authentication. This can be clarified in the draft.
>>
>
> configuration options are coming from a trusted source.. TLS authentication
>> Are you saying here that, because there is no typically-trusted way to
>> get this information from DHCP, there should be no way to get it from the
>> DNS either? If so, that seems like a harsh restriction.
>>
>
> Google DoH/DOT server instead of OpenDNS.. Assuming Google does not block
>> The draft clearly says that a resolver can self-publish any information
>> it wants, so I don't understand the question.
>>
>
> If DNSSEC is mandatory to implement by the endpoint, it should be
> specified in the document. Please note  neither
> https://tools.ietf.org/html/rfc8310 nor
> https://tools.ietf.org/html/rfc8484 mandate the use of DNSSEC.
>
>
>>
>> Given the above, and given that the WG would be able to change any part
>> of the draft it wants, do you still feel that way?
>
>