On Fri, May 25, 2018 at 8:08 AM, Sara Dickinson <[email protected]> wrote:
> > > > > > The happy eyeballs reference looks to be the right thing to do. > > Section 3: I’d like to see a bit more discussion around this proposal: > "A resolver working in opportunistic mode should try ports 53 and 853 in > parallel.” > > In addition to the privacy concern that Sara makes below (and with which I agree), it's actually not what the current specification of Happy Eyballs says. RFC 8305 says instead: Once the list of addresses received up to this point has been constructed, the client will attempt to make connections. In order to avoid unreasonable network load, connection attempts SHOULD NOT be made simultaneously. Presuming we treat the "address" here as a tuple of IP address and port and give a preference for 853 in the sorting algorithm, you'd end up starting with it and then going to 53 only after the default delay expired. I think that's better than concurrent attempts on several fronts. regards, Ted > I see the obvious latency win here but the downside with this mode (as > currently described) is that it _always_ leaks the query in cleartext so it > seems to defeat the point of using TLS. Unless the should (SHOULD?) here is > allowing for resolver behaviour where it has some cached knowledge of this > authoritative's capabilities and so could choose to probe all addresses > over 853 before falling back to 53? If so I think that should be spelled > out more clearly. > > I’d always seen opportunistic as ‘try for the best but be willing to > fallback to the worst case’ which isn’t exactly the same as ‘happy > eyeballs’ which I see as try everything in parallel? > > > > > The draft states: > > > >> If it is a concern that the same authoritative name servers are used > >> for ordinary DNS and for encrypted DNS, > > > > I don't know that should be, but if so it probably should discuss why > > some may find it to be a concern. > > Is this related to the monitoring/data retention/privacy policies by the > operator? In other words that the concern is they treat all the data as if > it were unencrypted…. > > > > > I think we should discuss whether an EDNS option to signal a successful > > authentication or failure really is out of scope, as the draft says. > > Interesting yes, but rogue or broken clients could easily send false > responses so I’m unsure of how useful this is? What would the specific use > case be? > > > One other comment - in RFC8310 there is discussion of the possible attacks > on meta queries (used here to obtain the TLSA records) - it seems the same > concerns apply here too and should be mentioned in the Security > Considerations? > > Regards > > Sara. > > > > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
