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

[tirumal reddy <[e-mail]>]

On Thu, 4 Apr 2024 at 12:07, <[e-mail]> wrote:

> Hi Warren,
>
> Thank you for the review. Much appreciated!
>
> A diff to track the changes can be found at:
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/add-resolver-information/draft-ietf-add-resolver-info.txt&url_2=https://boucadair.github.io/add-resolver-information/boucadair-patch-2/draft-ietf-add-resolver-info.txt
> .
>
> Please see inline for more context.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Warren Kumari via Datatracker <[e-mail]>
> > Envoyé : mercredi 3 avril 2024 22:10
> > À : The IESG <[e-mail]>
> > Cc : [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; [e-mail]
> > Objet : Warren Kumari's Discuss on draft-ietf-add-resolver-info-12:
> > (with DISCUSS and COMMENT)
> >
> > 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.)
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> >
> > 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.
>
> [Med] As a background, this specification covers the following item in the
> ADD WG Charter:
>
> "Define a mechanism that allows communication of DNS resolver
> information to clients for use in selection decisions. This could be
> part of the mechanism used for discovery, above."
>
> The draft sets the base for a mechanism for resolvers to explicitly reveal
> key properties that will be useful for server selection. An initial set of
> properties is defined here, but more can be registered in the future.
>
> >
> > 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
>
> [Med] ... which I guess you configured manually, because you trust it at
> the first place. I don't know if you will maintain that same resolver, if
> for example, you have been told that resolver filters/blocks some specific
> queries, does not limit the amount of information it leaks upstream, etc.
>
> , which happens to
> > support RFC
> > 8914 (Extended DNS Errors) and QNAME Minimization.
>
> [Med] One would glean this info here and there, but there is no formal
> claim from the resolver itself that it supports those.
>
>  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?
>
> [Med] That part is already covered by DNR/DDR and covered by this part of
> the charter:
>
> "This could be part of the mechanism used for discovery, above."
>
> >
> > "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?
>
> [Med] because you care about privacy, filtering, etc.
>
>  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".
>
> [Med] Tweaked the intro to make this clearer:
> https://github.com/boucadair/add-resolver-information/pull/30/commits/9ab541c54c1b6a4ade7583953cdc075823dab157
>
> >
> > "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...
>
> [Med] Thanks.
>
> NEW:
>
> "For example, the resolver selection procedure may use the retrieved
> information to prioritize privacy-preserving resolvers over those that
> don't enable QNAME minimization. However, that selection procedure is out
> of the scope of this document."
>
> >
> > 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?
>
> [Med] This excerpt is specific to DDR as called out it explicitly in the
> text:
>
>    If the Special-Use Domain Name "resolver.arpa", defined in [RFC9462],
>    is used to discover an encrypted DNS resolver,
>

In case of DDR (RFC9462), authenticated encrypted connection is mandatory
to the resolver, please see Section 7 of the draft.

<snip>

   DNS clients communicating with discovered DNS resolvers *MUST *use one
   of the following measures to prevent DNS response forgery attacks:
*   1.  Establish an authenticated secure connection to the DNS resolver.*

   2.  Implement local DNSSEC validation (Section 10 of [RFC8499]) to
       verify the authenticity of the resolver information.
*   It is important to note that, of these two measures, only the first
   one can apply to queries for 'resolver.arpa.*


</snip>



>
>  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).
>
> [Med] We wanted to avoid redundant statements in the document, but the
> security section states the following:
>
>    DNS clients communicating with discovered DNS resolvers MUST use one
>    of the following measures to prevent DNS response forgery attacks:
>
>    1.  Establish an authenticated secure connection to the DNS resolver.
>
>    2.  Implement local DNSSEC validation (Section 10 of [RFC8499]) to
>        verify the authenticity of the resolver information.
>
> >
> > 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.
>
> [Med] Good catch. Fixed at:
> https://github.com/boucadair/add-resolver-information/pull/30/commits/fcc293e88b9b75887923d3207740afd9a7f628db
>
> >
> > 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?
>
> [Med] Added this NEW:
>
> "Once a resolver is selected, this document does not interfere with DNS
> operations with that resolver."
>
>  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?


Added text to explain how the scenario can be handled:
If the resolver's capabilities are updated to include new error codes, the
resolver can terminate the TLS session, prompting the client to initiate a
new TLS connection. This allows the client to become aware of the
resolver's updated capabilities.


> 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?
>
> [Med] We already added this text per Erik's review:
>
> "If a group of resolvers is sharing the same ADN and/or anycast address,
> then these instances SHOULD expose a consistent RESINFO."
>
> >
> > 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
>
> [Med] Already added this text to address other reviews:
>
> NEW:
> That information is scoped to cover properties that are used to infer
> privacy and transparency policies of a resolver. Other information can be
> registered in the future per the guidance in {{key-reg}}.
>
>
>  -- 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?
>
> [Med] This provided in the sec cons:
>
> "local policy (e.g., user configuration, administrative configuration, or
> a built-in list of reputable resolvers)"
>
>  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!!!"
>

We can remove the text to display this info to the end-user even for
trusted resolvers.


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


The attributes ("qnamemin" and "exterr") defined in this spec cannot be
validated by the client but attributes defined in future specifications
could possibly be validated by the client.

Cheers,
-Tiru

>
>
> [Med] Will double check that part.
>
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>