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

[Petr Špaček <[e-mail]>]

On 13. 07. 21 0:28, Warren Kumari wrote:
> On Mon, Jul 12, 2021 at 6:18 PM Viktor Dukhovni <[e-mail]> wrote:
>>
>> [ Resending complete message, previous draft was incomplete... ]
>>
>>> On 12 Jul 2021, at 11:18 am, Paul Hoffman <[e-mail]> 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