Re: [DNSOP] [Ext] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

"

On Mon, Jul 12, 2021 at 6:18 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>
> [ Resending complete message, previous draft was incomplete... ]
>
> > On 12 Jul 2021, at 11:18 am, Paul Hoffman <paul.hoffman@icann.org> 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.
>
> 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, ...
>
> 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

>
> --
>         Viktor.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra