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

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

On 08. 07. 21 18:15, Brian Dickson wrote:
> 
> 
> On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček <[e-mail] 
> <mailto:[e-mail]>> 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/
>     <https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/>
>      > and
>      >
>     https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/
>     <https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/>
>      >
>      > If resolving " _ldap._tcp.ad.example.com
>     <http://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 <http://tcp.mail.example.org>"
>      > and the algorithm has already searched for "mail.example.org
>     <http://mail.example.org>", the
>      > next query can be for all the underscore-prefixed names together,
>      > namely "_25._tcp.mail.example.org <http://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?

Of course, I did, and I'm not too fond of the tone you used above. Let's 
skip to the constructive part, please.


 > It is a known fact that there ARE implementations where ENT handling (on
 > the authoritative side) are broken.

I agree that there are some, but anecdotal evidence of existence tells 
us nothing about
a) prevalence
b) significance of these broken auths and domains hosted on them.
AFAIK both of these are parameters taken into account by resolver 
vendors when deciding what types of non-compliance need to be worked around.

I'm arguing against mandating workarounds. The recommendation might be 
sound in 2021, but that's not a good enough reason for me to mandate it 
as it might change next month when one major player fixes its deployment.


Historical context:
Based on experience with Knot Resolver, various workarounds present in 
older resolver implementations were not "needed" by the time Knot 
Resolver came about. Multiple types of formerly-prevalent protocol 
non-compliance became so marginal that it was not worth the complexity 
to implement and maintain workarounds for them anymore.



 > 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)?

When you reach this line, I think it should be clear that I consider 
this a wrong question. We should be asking why RFC should mandate a 
workaround that might get obsolete in an inestimable amount of time.

Need for workarounds changes, and for this reason I don't consider RFCs 
to be a good place to _mandate_ workarounds which are by definition 
dependent on current (and constantly changing) situation. (To be clear, 
describing workarounds without mandate is fine with me!)

I hope it clears up why I'm against mandating this.

Petr Špaček @ ISC


> 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.