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

[[e-mail]]

Warren,

Please use this link to track all the changes: Diff: draft-ietf-add-resolver-info-12.txt - draft-ietf-add-resolver-info.txt<https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-add-resolver-info&url_2=https://boucadair.github.io/add-resolver-information/draft-ietf-add-resolver-info.txt>.

Cheers,
Med

De : Add <[e-mail]> De la part de tirumal reddy
Envoyé : jeudi 4 avril 2024 09:45
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Warren Kumari <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: [Add] Warren Kumari's Discuss on draft-ietf-add-resolver-info-12: (with DISCUSS and COMMENT)

On Thu, 4 Apr 2024 at 12:07, <[e-mail]<mailto:[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]<mailto:[e-mail]>>
> Envoyé : mercredi 3 avril 2024 22:10
> À : The IESG <[e-mail]<mailto:[e-mail]>>
> Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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
____________________________________________________________________________________________________________
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.