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

[tirumal reddy <[e-mail]>]

Hi Paul,

Please see inline

On Tue, 2 Apr 2024 at 19:33, Paul Wouters <[e-mail]> wrote:

> On Tue, 2 Apr 2024, [e-mail] wrote:
>
> > 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)
>
> >               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.
>
> This is sadly another instance of this problem yes. You are defining
> protocol and server side but not client side. Whenever a security
> issue comes up that would need client consideration, this escape
> hatch is used. It is basically ignoring security issues raised.
>
> >  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
>
> Sure, although I would be surprised if a network rolls out handing out
> different nameservers to use with different policies enabled on them.
>

For instance, an endpoint with multiple interfaces could pick the interface
over which the discovered encrypted resolver 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.
>
> If it notifies the DNS client, this becomes a security issue. It is
> basically telling the client "expect DNSSEC indeterminate or bogus
> resolutions". It is exactly what a rogue network would say that
> is attacking the user.
>

The client knows the responses will be modified and can decide whether to
use the discovered resolver or not. The client can anyways use Extended DNS
Error Code to identify if the response is modified. The resolver
information helps the client learn about filtering capabilities even before
making a DNS query. For instance, NextDNS configured as a TRR in Firefox
performs DNS filtering to block malware and phishing sites.


>
> > [Med] ACK. The WG charter has the following:
> >
> > “Making any recommendations about specific policies for clients
> > or servers is out of scope.”
>
> As previously discussed on other documents, you can't really specify
> server behaviour without client behaviour. It is an incomplete security
> model.
>
> >       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.
>
> Which is provisioning (by enterprise or phone vendor) and leads to more
> (DNS) centralization that I consider harmful for the internet to build
> into our protocols.
>
> >       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.
>
> That does not answer my qustion.
>

The key outcome of the draft is to define the new RR and that the resolver
information can be extended in future specifications. For instance, whether
the resolver supports DoH or DoT or DoQ is discovered by the client using
the SVCB record (see https://datatracker.ietf.org/doc/rfc9461/). The other
parameters like the DNS version can be advertised in a new attribute, but
we need to assess the risk of advertising it to the client. I don't think
0x20 support is an RFC.


>
> > [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.
>
> Now it gets more complicated. Benefiting the DNS client, but we can't
> talk about exactly how this affects the DNS client behaviour as it is
> out of scope. So it says "this helps the DNS client's security, but
> we cannot discuss this in detail as DNS client policy is out of scope".
>
> >       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?
>
> This is unanswered.
>

The client cannot validate whether the server is lying or not about the
"qnamemin". Therefore, it's essential for the client to consider the
reputation of the resolver.


>
> >       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.
>
> Okay, that is clearer, thanks.
>
> > [Med] Please see: Paul's review by boucadair · Pull Request #29 ·
> boucadair/add-resolver-information (github.com)
> >
> >
> >
> >       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.
>
> The goal I understand, the approach to get to that goal I don't.
>
> >
> >       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.
>
> What is insecure about HTTP when the target URL is advertised and
> available to everyone? Are you afraid someone attacks this stream
> of data and rewrites it? What would be attack be useful for ?
>

I don't know the usefulness of the attack but it prevents an on-path
attacker from modifying the HTTP response.

Cheers,
-Tiru


>
> >       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.
>
> But we are not talking about endusers here but about IT administrators,
> so whether or not the enduser trusts this is not relevant?
>
> >
> >               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.
>
> See my earlier point about this protoocl stimulating internet
> centralization.
>
>
> I will think about what to do with my ballot. Thanks for the answers
> provided.
>
> Paul
>
>