> On 18 May 2018, at 19:25, James Cloos <[email protected]> wrote: > >>>>>> "BH" == Brian Haberman <[email protected]> writes: > > BH> What I will ask now is that those who are interested in the current > BH> draft to start providing detailed reviews …
I’ve read the draft again - comments below. > > The draft asks whether tls 1.3 should be the minimum version. > > It would be better for this document to specify >= 1.2. It will be much > easier in the short term to add 1.2 support to existing machines than 1.3 > and that would allow much more real testing during the draft state. I agree with this. At this stage TLS 1.2 is much more practical and I think just referencing BCP7525 is enough. > > 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.” 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
