Re: [Add] Paul Wouters' Discuss on draft-ietf-add-resolver-info-12: (with DISCUSS)

[[e-mail]]

Hi all,

Please see inline.

Cheers,
Med

De : tirumal reddy <[e-mail]>
Envoyé : lundi 1 avril 2024 14:30
À : Paul Wouters <[e-mail]>
Cc : The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: Paul Wouters' Discuss on draft-ietf-add-resolver-info-12: (with DISCUSS)


Hi Paul,

Thanks for the review. Please see inline

On Sun, 31 Mar 2024 at 07:21, Paul Wouters via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Paul Wouters 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:
----------------------------------------------------------------------


In general, I am not sure what this document wants to achieve.

It states:

        DNS clients can use the resolver information to identify the
        capabilities of DNS resolvers.

It then defines qnamein, exterr and infourl. The latter should not be used
by the DNS client. So what should a DNS client do with the information
that QNAME Minimalization is used, or that the DNS resolver code base
supports EDE (but EDE might not be in use anyway). What behavioral
change is expected from "DNS Clients" that are targeted by this document?
If no change in behavior is expected, why should a DNS client support and
perform this query?

The specific policy on how the client will use the discovered resolver information is outside the scope of ADD WG charter. Hence, the behavior change expected from DNS clients is not explicitly defined. For instance, the client may give higher precedence to a resolver that offers QNAME minimization versus a resolver that does not support it. Another example, could be the client could notify the end-user that the resolver will perform filtering (e.g., EDE codes 4 and 16). This notification can help to inform the end-user and client about the resolver's error handling capability.

[Med] ACK. The WG charter has the following:

"Making any recommendations about specific policies for clients
or servers is out of scope."



Furthermore, none of the answers can be trusted without some form of
enterprise provisioning.

No, browsers can be pre-configured with trusted recursive resolvers offered by ISPs.


Why inform the resolver is using qname minimalization? What makes this
optional special, compared to other things like 0x20 support, the infra-rr
hardering support, DNSSEC support? Why is it not providing keywords for
DoH or DoT or DoQ support? Why not show what normally would be in the
CHAOS version.bind data like dns implementation name and version?

The WG has agreed on the three attributes and a registry is added with specification required as the registry procedure to add new
attributes in future specifications.
[Med] Added a new sentence to clarify the rationale for selecting this **initial** set of information:

NEW:
   That information is selected because it
   provides benefits to the security and privacy of DNS data.  Other
   information can be registered in the future per the guidance in
   Section 8.2.


If the DNS client would behave differently based on the setting of
qnamein, what would it be and how would it determine the security of
the returned value (eg why wouldn't the target DNS resolver just lie to
cause the DNS Client to do whatever behavior it does differently when
it sees qnamein?). If this is meant only for administrators doing DNS
diagnostics, why not ONLY return an infourl and have qnamein and exterr
contained in infourl, or even more keywords based on a DNS yang model
list of keywords?

What is the DNS Client expected to do with the exterr values returned?
What does "supported" mean, eg versus "configured".

It means the DNS server is configured to return the exterr values. we will replace "supported" with "configured" for clarity.
[Med] Please see: Paul's review by boucadair · Pull Request #29 · boucadair/add-resolver-information (github.com)<https://github.com/boucadair/add-resolver-information/pull/29/files>

What different
DNS Client behavior is expected based on this value?

The "infourl" seems a bit risky. While the documents tries to limit
the impact, I don't understand its approach.

The "infourl" is typically meant for IT staff for troubleshooting purposes.


Why insist on "https" ? It's a public API that anyone that can query
the nameserver can presumably retrieve anyway? That is, I assume such
a infourl would not require HTTP level authentication. I don't see why
it should be forced over https.

Yes, HTTP level authentication is not required. HTTPS was explicitly mentioned to avoid providing the information over insecure HTTP.


Why is the information presented a text/html and not plaintext ? Or
json? Or yang? This would avoid various risks of exposure to the enduser
which are not meant to consume this anyway according to the document.

        The URL SHOULD be treated only as diagnostic

Why is that not the case for qnamein and exterr?
Why is that not a MUST?

[Med] because this can be relaxed by the condition in the MAY right after.


        A DNS client MAY choose to display the URL to the end user

Why is this not a MUST NOT ?
[Med] Because a user can have a policy to trust a specific resolver.


        if and only if the encrypted resolver has sufficient reputation

This is not something an implementer can write code for reading the RFC.
It further more pushes centralization towards "reputable DNS resolvers".
How does the DNS client get updates about the reputable status of a DNS
resolver?

DNS clients, such as web browsers, typically update their trusted recursive resolvers (TRR). The process of updating the TRR can happen through software updates or other automated mechanisms.

-Tiru


I feel just like "captive portals", that this can/will be misused and be used
for advertisement or other non-DNS purposes. Forcing this to be text/plain
or json/yang would make this "less consumable" to endusers and thus make them
more safe against abuse.

In Section 7 it states:

        1. Establish an authenticated secure connection to the DNS resolver.

        [...]

        It is important to note that, of these two measures, only the
        first one can apply to queries for 'resolver.arpa'

How can anyone establish a secure authenticated connection to
"resolver.arpa"?

No, the above text is referring to DNR (and not DDR).

Cheers,
-Tiru


If they do, either the client has to authenticate it is the real
"resolver.arpa" but then its contents cannot apply (it's something on
the internet, not local) or it authenticates to "something else", in
which case how can that be secure, or if it is secure but populated with
information that validates "starbucks", how meaningful is "authentication"
in this context?

The section contains another set of "weasel wording" on determining
reputation of the resolver that is not really implementable in code.




____________________________________________________________________________________________________________
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.