On 13. 07. 21 0:28, Warren Kumari wrote:
On Mon, Jul 12, 2021 at 6:18 PM Viktor Dukhovni <[email protected]> wrote:
[ Resending complete message, previous draft was incomplete... ]
On 12 Jul 2021, at 11:18 am, Paul Hoffman <[email protected]> wrote:
The current text is sufficient to tell resolver developers, and resolver
operators, why they should even think about underscore labels when they create
a QNAME minimisation strategy. Elevating such a strategy to a SHOULD as a
work-around for broken middleboxes that might (hopefully!) be fixed in the
future seems like a very wrong direction for the WG.
If this were just a work-around for breakage, I'd be more inclined
to agree, but it is also a solid opportunity to improve performance,
because privacy-relevant changes of administrative control across
special-use labels should be very rare to non-existent.
I hear you Viktor, but I fail to see why performance optimization cannot
be optional. Why this specific optimization is so important that it
cannot be left to vendors to decide?
So short-circuiting qname minimisation when a special-use label is
encountered seems like a win-win.
Measuring qname minimisation for TLSA RRs I see that today breakage
of qname minimisation is rare. An example is:
https://dnsviz.net/d/_tcp.u24.altospam.com/YOx4nQ/dnssec/
https://dnsviz.net/d/_25._tcp.u24.altospam.com/YOx4IA/dnssec/
In which many (but not all) of the nameservers return NXDOMAIN for the
ENT. Out of 150k RRsets, O(10) have ENT-related issues.
So one might reasonably neglect the breakage, but it is not clear that
we need to go looking for it, just to "punish" the operators in question.
There's an opportunity here to make qname minimisation more performant for
SRV, TLSA, ... lookups, speeding up Domain Control and LDAP server lookups,
email delivery, ...
Please note I do not object to the method by itself - I agree it might
be useful. My disagreement is limited to using stronger requirement than
MAY. Let vendors have some leeway, please.
Petr Špaček
Of course if the WG cannot come to consensus on "SHOULD"/"RECOMMENDED", I'll
gratefully settle for the current "MAY" (thanks for the document update)...
Another option would be to keep the current text, and simply add
another sentence describing why implementations may want to do this;
the current paragraph starts off with:
" 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." - the context around this is mainly around limiting the
many labels attack, but it could also mention the ENT / other
performance gain.
Whatever the case, this conversation is still ongoing, so I'd like to
keep it open for a few more days...
W
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
