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

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

On 13. 07. 21 0:13, Brian Dickson wrote:
> 
> 
> On Mon, Jul 12, 2021 at 2:20 AM Petr Špaček <[e-mail] 
> <mailto:[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]>
>      > <mailto:[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/>
>      >   
>       <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
>