Subject: [Add] Fwd: New Version Notification for draft-reddy-add-server-policy-selection-06.txt

From: tirumal reddy <[email-masked]>
Date: Wed, 24 Feb 2021 11:24:48 +0530

The revised draft
https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-06
addresses comments from the WG and aligns with the requirements of
“Resolver behavior self-description” presented at ADD interim.

Further comments and suggestions are welcome.

Cheers,

-Tiru

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sun, 21 Feb 2021 at 12:54
Subject: New Version Notification for
draft-reddy-add-server-policy-selection-06.txt
To: Michael C. Richardson <[email-masked]>, Tirumaleswar Reddy.K <
[email-masked]>, Dan Wing <[email-masked]>, Mohamed Boucadair <
[email-masked]>

A new version of I-D, draft-reddy-add-server-policy-selection-06.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:           draft-reddy-add-server-policy-selection
Revision:       06
Title:          DNS Server Selection: DNS Server Information with Assertion
Token
Document date:  2021-02-20
Group:          Individual Submission
Pages:          24
URL:
https://www.ietf.org/archive/id/draft-reddy-add-server-policy-selection-06.txt
Status:
https://datatracker.ietf.org/doc/draft-reddy-add-server-policy-selection/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-add-server-policy-selection
Htmlized:
https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-06
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-add-server-policy-selection-06

Abstract:
   The document defines a mechanism that is meant to communicate DNS
   resolver information to DNS clients for use as a criteria for server
   selection decisions.  In particular, the document defines a mechanism
   for a DNS server to communicate its filtering behavior to DNS
   clients.  Such an information that is cryptographically signed to
   attest its authenticity is used for the selection of DNS resolvers.
   Typically, evaluating the filtering behavior and the signatory, DNS
   clients with minimal or no human intervention can select the DNS
   servers for resolving domain names.

   This assertion is useful for encrypted DNS (e.g., DNS-over-TLS, DNS-
   over-HTTPS, or DNS-over-QUIC) servers that are either public
   resolvers or discovered in a local network.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 25 Feb 2021 10:59:01 -0500

> “Resolver behavior self-description” presented at ADD interim.

The draft's abstract and introduction have been adjusted to align better
with the purpose stated in that presentation, but In my view the content
does not align well.

As the title suggests, this draft is concerned principally with policy,
whereas that presentation focused on the resolver's identity and observable
behaviors.

Here's the relevant text from that presentation:

## Defining resolver identity
* Express information consumable by humans describing the resolver's
identity
* Ex 1: Provide human-legible documentation
    * Most likely a web page link to explain server identity, terms of use,
etc.
* Not used for decision making by any protocol peer; communicated to
clients for display to users
* Ex 2: Provide human-friendly description of the resolver identity
    * Friendly name and/or iconography for display in client UI identifying
configured resolver

## Defining protocol support
* Express what optional DNS-related functionality is supported
* Ex 1: DNS Extended Errors and which codes to expect
      * Not exhaustive: server can still return any code
      * Codes 15-17 indicate kinds of filtering the resolver implements
* Ex 2: Access-controlled resolvers describing their properties outside of
access control

The draft does some, but not all, of these things, and also does a lot more
that is, in my view, separable, out of scope, or undesirable.

I would start by separating the Policy Assertion Token and signature system
into its own draft.  That signature scheme is interesting but is not
required to meet these goals.  I would also avoid any metadata keys beyond
those mentioned in the presentation, so we can focus on constructing a
suitable extensible format for metadata delivery.  More keys can be added
as extensions in subsequent drafts.

For delivery, I think the best option might be a TXT record in DNS-SD style
on _dns.$RESOLVER_NAME and _dns.resolver.arpa.  That should make manual
debugging easy and familiar for DNS administrators.

If you'd like to proceed in this direction, I'm happy to help.

---

From: tirumal reddy <[email-masked]>
Date: Fri, 26 Feb 2021 13:42:52 +0530

Hi Ben,

Thanks for the review. Please see inline

> whereas that presentation focused on the resolver's identity and observable

The draft does not discuss any policy, it's scope is restricted to
publishing resolver information. Please clarify what policy information you
are referring to that needs to be removed.

>     * Most likely a web page link to explain server identity, terms of
> use, etc.
>

The above information is provided using

 resinfourl:  A URL that points to the generic unstructured resolver
      information (e.g., DoH APIs supported, possible HTTP status codes
      returned by the DoH server, how to report a problem, etc.) for
      troubleshooting purpose.  This is an optional attribute.

> clients for display to users

"resinfourl" is not used for any decision making by the end-user.

>     * Friendly name and/or iconography for display in client UI
> identifying configured resolver
>

The challenge with above information is it could be displayed in a language
not understood by the user. It is not possible to support the above
requirement without knowing the languages the user is able to understand.

>       * Codes 15-17 indicate kinds of filtering the resolver implements

All the above information is conveyed using "extendeddnserror",
"policyblocking", "censoredblocking" and "filteredblocking" attributes
(Codes 15 to 17).

> * Ex 2: Access-controlled resolvers describing their properties outside of

It is saying whether the server needs client authentication, it is handled
by the "clientauth" attribute.

>
> The draft does some, but not all, of these things, and also does a lot
> more that is, in my view, separable, out of scope, or undesirable.
>

Please specify the ones missing and undesirable, we will update the draft
accordingly.

>
> I would start by separating the Policy Assertion Token and signature
> system into its own draft.  That signature scheme is interesting but is not
> required to meet these goals.
>

The signature is added to ensure the client does not connect to an
encrypted DNS server hosted by an attacker. The resolver information can be
conveyed either inside the PAT or separately (please see step 6 in
https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-06#section-9
).

> I would also avoid any metadata keys beyond those mentioned in the
> presentation, so we can focus on constructing a suitable extensible format
> for metadata delivery.  More keys can be added as extensions in subsequent
> drafts.
>

Sure but PAT is a mandatory resolver information especially in scenarios
where Encrypted DNS server is discovered insecurely.

>
> For delivery, I think the best option might be a TXT record in DNS-SD
> style on _dns.$RESOLVER_NAME and _dns.resolver.arpa.  That should make
> manual debugging easy and familiar for DNS administrators.
>

The previous version of the draft was relying on RESINFO (RESINFO draft is
adopted in DNSOP but expired and not making any progress). The current
version of the draft is updated to use SVCB RRtype to align with DDR.
Most importantly, https://tools.ietf.org/html/rfc5507 discusses why using a
new RR Type is a preferred solution rather than relying on TXT resource
record.

> If you'd like to proceed in this direction, I'm happy to help.

Thanks, glad to work with you on this and make progress.

Cheers,
-Tiru