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

[Brian Dickson <[e-mail]>]

On Mon, Jul 12, 2021 at 2:20 AM Petr Špaček <[e-mail]> wrote:

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

Let me start by apologizing to you (and the group) for the tone (whether
intended or not).
(I was literally inquiring as opposed to intending to having tone.)


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

So, let me counter by illustrating the scope of the problem, if it occurs,
and the challenges created depending on whether or not any work-around is
RECOMMENDED, or not.

This is specifically concerned only with underscore names which are
registered with IANA, and the implications of ENT-based resolution errors.
For reference, the list is published here:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Not all entries in the underscore table have the same degree of
utilization, or relevance, etc.

The ones that jump out from that list, as well as not-yet-published
entries, at least in my opinion, are:

   - TLSA
   - SVCB
   - DMARC
   - DKIM
   - ACME
   - validation-contactemail
   - validation-contactphone
   - SPF use of _spf
   - X.509 URIs
   - DNS SD

The reason I'm interested in ensuring that the REASON (rationale) matches
the CHOICE we make in the WG, is precisely that the collective knowledge
about the deployment prevalence and issues is little better than anecdotal.
And, that the impact of picking one (MAY vs SHOULD) might affect lots of
other applications and protocols.

DNS is a necessary and fundamental service, used by not only the various
parties (end-users and servers, zone owners) but also the services which
rely on the DNS itself and proper resolution of entries in the DNS.

The problem MAY be present in middle-boxes (of all sorts of functions and
flavors), but MAY NOT be anything under operator control, and might not be
easy to identify.
The problem MAY ALSO exist in other software, firmware, or hardware, which
is acting as an actual DNS device (rather than multi-function middlebox).

So, basically, my suggestion is, that if the WG wants to use "MAY", it
should ensure the guidance to implementers is clear, on what might happen,
and if it does, how to detect it, report it, and what documentation to
provide to operators/users.

The old adage of, "Never test for an error condition you don't know how to
handle" has relevant corollaries here:

   - If you do know how to handle an error condition, test for it and
   handle it
   - If you are unable to test for an error condition, maybe don't create
   it in the first place
   - Don't blame the victim

Examples of problems that aren't easy or even possible to fix, and may not
be possible to work around, include (but are not limited to):

   - Mandated services or equipment
   - Service-provider (ISP) provided equipment
   - Consumer-grade equipment without support
   - Third party operators of services (e.g. DNS)
   - MITM functionality (e.g. government-operated, or public WiFi operated,
   or hotel service, etc)

The implications to borked stuff, based on the underscore registry entries
highlighted could include:

   - Loss of privacy
   - Inability to validate certificates or to discover revoked certificates
   - Loss of spam-prevention ability to receivers
   - Loss of spam-prevention protection to domain owners
   - Inability to discover services
   - Degradation of web performance
   - Inability to auto-renew certificates

The current text does not provide any guidance on the broken-ENT-NXDOMAIN
problem, and basically ignores the problem entirely.

If keeping MAY is the approach chosen, I would like to suggest that some
text be added to the effect that (a) the specific ENT problem may exist,
and (b) what to do to detect it and handle it, or whether to add a "knob"
to add support for operators to enable such support.

I'm not sure if Viktor has already supplied language that would work.

If not, something like this (but maybe easier to read, parse, implement,
etc) would be helpful:

"When doing QNAME minimization, if an iterative query whose first label
begins with an underscore "_", results in an NXDOMAIN, the owner name may
be an ENT (empty non terminal). A signed response would include a proof of
non-existence, and no additional action is needed in that situation.
However, an unsigned response MAY be treated as a possible indicator of an
ENT, and the algorithm MAY choose to ignore the NXDOMAIN if the current
QNAME is not the same as the original QNAME, and proceed to the next label
in the algorithm."

There is a difference between mandating workarounds, and supporting use
cases where the impacted party is not in a position to change the outcome
of failed DNS resolution.

Brian

P.S. I am genuinely interested in what implementers plan on doing,
regardless of whether that is mandated or not. If anyone is willing to
share, please do so.


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