[Add] Warren Kumari's Discuss on draft-ietf-add-resolver-info-12: (with DISCUSS and COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-add-resolver-info-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Be ye not afraid -- see
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ on
handling ballots, especially DISCUSS ballots...

I'd like to start off by apologizing for the tone of this DISCUSS - I know that
you've put a lot of work into this document, and getting a review like this is
frustrating. I suspect that a fair bit of my concern can be addressed by having
the document be much clearer about the intended use case / what the actual
problem is that it is solving.

My DISCUSS is quite similar to Paul Wouters' -- there is much in this document
which seems unclear and/or underspecified and/or incomplete.

As an initial example, the Introduction starts off with:
"Historically, DNS clients communicated with recursive resolvers without
needing to know anything about the features supported by these resolvers. 
However, recent developments (e.g., Extended Error Reporting [RFC8914] or
encrypted DNS) imply that earlier assumption no longer generally applies."

I don't really see how "that earlier assumption no longer generally applies" --
my laptop is configured to use Google Public DNS, which happens to support RFC
8914 (Extended DNS Errors) and QNAME Minimization. My laptop happily
communicates with 8.8.8. without knowing **anything about the "features
supported by these resolvers"**. I *could* see an argument being made that my
laptop should know if the resolver supports various flavors of encrypted DNS so
that it knows to connect over an encrypted transport, but that's what RFC9462,
RFC9463 are for, no?

"Instead of depending on opportunistic approaches, DNS clients need a more
reliable mechanism to discover the features that are supported by resolvers."
Similar to the prior -- why do clients *need* this? My laptop is currently
working just fine without it. The document seems to have this base assumption
throughout, but it doesn't really seem to justify it -- I'm hoping / assuming
that this is sufficiently obvious within the WG that it was just omitted
because "everyone knows".

"Retrieved information can be used to feed the server selection procedure.
However, that selection procedure is out of the scope of this document." -- is
this the justification for all of the above assertions? If so, I think that A:
the document needs to be much more explicit about this (don't "bury the lede")
and B: some sort of advice about *how* is would be used seems needed -- I get
that you don't want to specify the whole selection procedure, but something
like "the server selection procedure could use this to prioritize
privacy-preserving resolvers over those that don't do QNAME minimization" or
similar...

Section 3:
"If the Special-Use Domain Name "resolver.arpa", defined in [RFC9462], is used
to discover an encrypted DNS resolver, the client can retrieve the resolver
information using the RESINFO RR type and QNAME of "resolver.arpa". In this
case, a client has to contend with the risk that a resolver does not support
RESINFO. The resolver might pass the query upstream, and then the client can
receive a positive RESINFO response either from a legitimate DNS resolver or an
attacker. The DNS client MUST set the Recursion Desired (RD) bit of the query
to 0. The DNS client MUST discard the response if the AA flag in the response
is set to 0, indicating that the encrypted DNS resolver is not authoritative
for the response." This says "In this case, a client has to contend with the
risk that a resolver does not support RESINFO." -- but surely that is true for
the other cases too? Many clients live behind DNS forwarders / middle-boxes,
which will happily pass unknown RR types upstream, but won't necessarily pass
e.g EDNS responses back. If one of these clients sees that the "resolver"
supports EDE, but the forwarder drops these, the client is being lied to.
Perhaps the techniques in this document are only allowed to be used over
encrypted DNS transports? This might be implied by the fact that you are
supposed to use "resolver.arpa" or "the QNAME of the domain name that is used
to authenticate the DNS resolver", but if so, this is really not clear in the
document. If that is indeed the case, the document needs to be much much more
explicit about this, and also discuss what happens if you query for this over a
non-encrypted protocol (which many resolvers won't actually know).

In addition, this says: "The DNS client MUST set the Recursion Desired (RD) bit
of the query to 0. The DNS client MUST discard the response if the AA flag in
the response is set to 0, indicating that the encrypted DNS resolver is not
authoritative for the response." - is the "indicating that the *encrypted* DNS
resolver" (and this section) implying that the RD bit must only be set to 0
when using the RFC9462 resolver.arpa mechanism, or whenever looking up RESINFO?
I'd assume the latter, but that conflicts with the "*encrypted* DNS resolver"
bit.

Why is it useful / important for a client to know that a resolver supports
specific EDE errors? E.g If RESINFO says that Resolver X supports
"exterr=15,16,17", and the resolver suddenly sends back Extended DNS Error Code
5 - DNSSEC Indeterminate, what should the client *do*? Is it a violation to
send back an EDE Code not covered by the capability list? What if I run a
resolver, and advertise "exterr=42", and then add additional support for codes
1, 2 and 3? I guess I have to wait for the TTL to expire before advertising
these? Seeing as the document doesn't really explain what the information is
used for, it's not clear when (other than at initial connection) a client would
re-query for it. Many resolvers are also anycast at this point -- what
capabilities should be advertised if the set is not uniform across all members?
The minimum enclosing set? The maximal set?

The document also lists qnamemin and exterr as the supported capabilities -
it's not at all clear why those ones were selected as important capabilities
and not e.g 0x20, port randomization, jurisdiction, logging level and
retention, favorite flavor of ice-cream, etc. If it is just that these happened
to be two capabilities that you happened to choose, I think that it would be
worth clarifying this -- the document does say "New keys can be defined as per
the procedure defined in Section 8.2.", but the focus on qname and EDE in the
text makes it sound like these are the primary uses.

infourl:
"It is not intended for end user consumption as the URL can possibly provide
misleading information. A DNS client MAY choose to display the URL to the end
user, if and only if the encrypted resolver has sufficient reputation,
according to some local policy" -- so, which is it? If a DNS client does
display this to the end user, they will consume it (and possibly be misled).
This also seems like it is ripe for phishing / advertising -- "Welcome to
BestHotels, thank you for using our wonderful Encrypted DNS server. For only
$19.95 per day, you can get the DNSSEC validating version of this service,
enter your Credit Card Below!!!"

Security Considerations:
"An encrypted resolver may return incorrect information in RESINFO. If the
client cannot validate the attributes received from the resolver, that will be
used for resolver selection or displayed to the end-user, the client should
process those attributes only if the encrypted resolver has sufficient
reputation according to local policy (e.g., user configuration, administrative
configuration, or a built-in list of reputable resolvers). " This feels very
hand-wavey / underspecified - "If the client cannot validate the attributes
received from the resolver, [...] the client should process those attributes
only if the encrypted resolver has sufficient reputation according to local
policy." I don't really understand this -- how could a client validate the
attributes? Surely not because they are DNSSEC signed / delivered over
encrypted DNS? (That doesn't prove that the data is correct, only that it is
what the resolver operator sent) So, how would a client validate that Resolver
X supports e.g EDE Codes 9, 10, 11? Does this just boil down to "Don't trust
any of this unless local policy says to?"


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Nits:
1: "imply that earlier assumption no longer generally applies."
s/assumption/assumptions/ (or "the earlier assumptions"). Also, I think
s/applies/apply/, or just rewrite this ending part.

2: It is not intended for end user consumption as the URL can possibly provide
misleading information. s/consumption as/consumption, as/  Also, I think that
"end-user" is the preferred usage, but I'm not sure.