Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information
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 wrote: > Hi Paul, > > Please see inline > > On Mon, 5 Aug 2019 at 19:56, Paul Hoffman > wrote: > >> Thank you for your detailed list >> >> On Aug 5, 2019, at 4:07 AM, tirumal reddy wrote: >> > >> > 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: >> >> 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 ? > > >> >> > 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. >> > > 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 ? > > >> >> > 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. >> > > 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). > > >> >> > 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. >> > > 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, >> > 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. >> > > 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. > > >> >> > 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. >> > > 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 ? >> >> Whichever decision it wants. This is true for any protocol, yes? >> > > No, the decisions may have privacy and security implications. > > >> >> > 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
Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information
Hi Paul, Please see inline On Mon, 5 Aug 2019 at 19:56, Paul Hoffman wrote: > Thank you for your detailed list > > On Aug 5, 2019, at 4:07 AM, tirumal reddy wrote: > > > > 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: > > 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 ? > > > 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. > 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 ? > > > 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. > 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). > > > 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. > 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, > > 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. > 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. > > > 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. > 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 ? > > Whichever decision it wants. This is true for any protocol, yes? > No, the decisions may have privacy and security implications. > > > 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
Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information
In article you write: >I support adoption, but I think we should consider a substantial >simplification of the design, focusing on a consensus core of basic >functionality. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information
+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 wrote: > On 4 Aug 2019, at 21:00, Martin Thomson wrote: > > > On Sun, Aug 4, 2019, at 00:37, Paul Hoffman 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. > > > > 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. > >> > >> 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. > > 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
Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information
Moin! On 5 Aug 2019, at 16:26, Paul Hoffman wrote: 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information
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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information
On Aug 5, 2019, at 5:52 AM, Joe Abley wrote: > 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. 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 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. 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 weakness that is worth > highlighting. We should definitely add this discussion to the draft if the WG adopts it. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information
Thank you for your detailed list On Aug 5, 2019, at 4:07 AM, tirumal reddy wrote: > > 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: 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information
On 4 Aug 2019, at 21:00, Martin Thomson wrote: > On Sun, Aug 4, 2019, at 00:37, Paul Hoffman 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. > > 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. >> >> 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. 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 signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information
On Sun, Aug 4, 2019, at 00:37, Paul Hoffman 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. 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. > > 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. 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. > > 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? 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
