Re: [DNSOP] Call for Adoption: draft-sah-resolver-information
On Mon, 5 Aug 2019 at 16:20, Ralf Weber wrote: > Moin! > > On 4 Aug 2019, at 4:15, Rob Sayre wrote: > > > On Fri, Aug 2, 2019 at 8:04 AM Tim Wicinski wrote: > > > >> > >> 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. > >> > > > > I don't understand what this draft aims to standardize, and I don't think > > 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) > 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 > > So long > -Ralf > —-- > Ralf Weber > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-sah-resolver-information
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 wrote: > > 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 > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-sah-resolver-information
Moin! On 4 Aug 2019, at 4:15, Rob Sayre wrote: > On Fri, Aug 2, 2019 at 8:04 AM Tim Wicinski wrote: > >> >> 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. >> > > I don't understand what this draft aims to standardize, and I don't think > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-sah-resolver-information
On Fri, Aug 2, 2019 at 8:04 AM Tim Wicinski wrote: 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-sah-resolver-information
On Fri, Aug 2, 2019 at 8:04 AM Tim Wicinski wrote: > > 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. > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-sah-resolver-information
On Sat, Aug 3, 2019, at 01:04, Tim Wicinski wrote: > 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Call for Adoption: draft-sah-resolver-information
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
