On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček <[email protected]> wrote:
> On 07. 07. 21 19:54, Warren Kumari wrote: > > Hi there all, > > > > I wanted to check the consensus on a point brought up during IETF LC / > > OpsDir review of draft-ietf-dnsop-rfc7816bis. > > > > Please see: > > > https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/ > > and > > https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/ > > > > If resolving " _ldap._tcp.ad.example.com", once you hit the _tcp label > > you are quite likely in ENT territory, and some implementations > > (especially those behind firewalls / middleboxes) are still broken. > > There is also a performance hit. > > > > Version 10 of the document added: > > "Another potential, optional mechanism for limiting the number of > > queries is to assume that labels that begin with an underscore (_) > > character do not represent privacy-relevant administrative > > boundaries. For example, if the QNAME is "_25._tcp.mail.example.org" > > and the algorithm has already searched for "mail.example.org", the > > next query can be for all the underscore-prefixed names together, > > namely "_25._tcp.mail.example.org"." > > > > (unsurprisingly the document does a much better job of explaining the > > issue than I did :-)) > > > > Viktor is suggesting that QNAME Minimization should be stopped when > > you run into an underscore ("_") label, instead of this being worded > > as a potential, optional mechanism. > > > > Obviously there is a tradeoff here -- privacy vs deployment. > > 1: while it's **possible** that there is a delegation point at the > > underscore label, (IMO) it is unlikely. If there is no delegation, you > > will simply be coming back to the same server again and again, and so > > you are not leaking privacy sensitive information. > > > > 2: some recursives are less likely to enable QNAME minimization > > because of the non-zero ENT and slight performance issues. > > > > What does the WG think? Does the privacy win of getting this deployed > > and enabled sooner outweigh the potential small leak if there *is* a > > delegation inside the _ territory of the name? > > > > Should the advice above be strengthened to SHOULD / RECOMMENDED? > > With my implementer hat on, I say "no", I don't see a compelling reason > to "mandate" it. Did you actually read what Viktor wrote? It is a known fact that there ARE implementations where ENT handling (on the authoritative side) are broken. Given that the vast majority of the first underscore queries would be hitting ENTs, this would seem to me, at least, to be compelling. Why would you not strongly suggest to other implementers to avoid this problem (by stopping the QNAME minimization)? Even if you, as an implementer, choose to ignore the problem? (Also, does your resolver code actually handle the situation during QNAME minimization of broken ENT handling by authoritative servers?) Respectfully, Brian Dickson > Keep it at MAY/optional level and leave it to > implementers to decide what's best for their implementation and use-cases. > > Thanks. > Petr Spacek @ ISC > > > > > > This is after IETF LC, but as the question was raised during LC, I > > think it needs to be discussed and addressed. > > > > I'd like a **clear** input, on this question only, by Tuesday August > 13th. > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
