On Wed, Jul 7, 2021 at 10:55 AM Warren Kumari <[email protected]> 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? > Yes. > > Should the advice above be strengthened to SHOULD / RECOMMENDED? > Yes. Brian > > 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. > > Much thanks! > W > > > -- > Perhaps they really do strive for incomprehensibility in their specs. > After all, when the liturgy was in Latin, the laity knew their place. > -- Michael Padlipsky > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
