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

[[e-mail]]

Hi Warren,

This is a kind nudge to check if the proposed changes [1] + clarification [2] address your concerns. 

Thank you 

Cheers,
Med

[1] 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  
[2] https://mailarchive.ietf.org/arch/msg/add/BZLE2i6h837Jaqg5x1ItwEw1jdw/

> -----Message d'origine-----
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : jeudi 4 avril 2024 08:37
> À : 'Warren Kumari' <[e-mail]>; The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : RE: Warren Kumari's Discuss on draft-ietf-add-resolver-info-
> 12: (with DISCUSS and COMMENT)
> 
> 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,
> 
>  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? 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!!!"
> >
> > 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?"
> >
> >
> 
> [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.