On 13. 07. 21 0:13, Brian Dickson wrote:
On Mon, Jul 12, 2021 at 2:20 AM Petr Špaček <[email protected]
<mailto:[email protected]>> wrote:
On 08. 07. 21 18:15, Brian Dickson wrote:
>
>
> On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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/>
>
<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/>
>
<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>
> <http://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>
<http://tcp.mail.example.org <http://tcp.mail.example.org>>"
> > and the algorithm has already searched for
"mail.example.org <http://mail.example.org>
> <http://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> <http://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.
I'm sorry for not replying in full, but I think it's more efficient this
way:
I agree that DNS is complex and has tons of failure modes, but this
specific case does not seem special enough to me to warrant special
treatment.
As Viktor pointed out in
https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/
, it seems that this problem plagues roughly tens out of 150k domains he
surveyed. I think this makes further discussion about _necessity_ of the
workaround kind of moot.
This leaves us with performance optimization, to which I replied already
in
https://mailarchive.ietf.org/arch/msg/dnsop/h9BlBI0hQ0MtDAQAK_s8Tmj2bUc/ .
Thank you for your time.
Petr Špaček @ ISC
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
<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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
