Re: [Add] I-D Action: draft-ietf-add-ddr-09.txt

[Ben Schwartz <[e-mail]>]

Following up on my SECDIR review:

Section 4

   Because this query is for an SUDN, which no entity can claim
   ownership over, the ServiceMode SVCB response MUST NOT use the "."
   value for the TargetName.  Instead, the domain name used for DoT/DoQ
   or used to construct the DoH template MUST be provided.  This ensures
   that different designated resolver configurations can be correctly
   associated with IP addresses in A and AAAA records.  As such, clients
   MUST NOT perform A and AAAA queries for "resolver.arpa".

Thanks for updating this paragraph, but I think there are still several
major issues here.

The guidance not to use "." is weird because using "." here would be
unnatural anyway.  The natural thing would be to set TargetName to
"resolver.arpa".  This is also forbidden, but the text doesn't address it.

The text about what to put in the TargetName is very strange.  It conflicts
directly with the guidance in Section 4.2 ("The client MUST verify that the
certificate contains the IP address of the designating Unencrypted DNS
Resolver") and Section 6.3 ("clients MUST use the original IP address of
the Unencrypted DNS Resolver as the URI host for DoH requests").

Also, as I noted in my review, the justification that "no entity can claim"
this name is illogical, as the resolver is already serving a response for
this name.  Clearly, the resolver can indeed "claim" this name, and is
already doing so.

Possible replacement text (along the lines suggested in my review):

> To enable reliable identification of the Designated Resolver for
debugging and future extensions, the TargetName SHOULD NOT indicate a SUDN
(either explicitly or via the special value ".").  Clients SHOULD NOT issue
speculative queries for A or AAAA records associated with this SVCB RRSet.
Note that the TargetName itself does not influence the encrypted connection
in any way.

Section 7:

   Section 8.2 of [I-D.ietf-add-svcb-dns] describes a second downgrade
   attack where an attacker can block connections to the encrypted DNS
   server.  For DDR, clients need to validate a Designated Resolver
   using a connection to the server before trusting it, so attackers
   that can block these connections can prevent clients from switching
   to use encrypted DNS.

I would prefer to make this more explicit, e.g. replacing the second
sentence with

> To bypass attacks that affect only one server, DDR clients SHOULD first
fall back to any other available Designated Resolver.  If none of the
Designated Resolvers are reachable, DDR clients MAY fall back to
unencrypted DNS (enabling a successful downgrade attack).  Any client that
does not fall back to unencrypted DNS MUST tightly limit the SVCB TTL,
which could have been chosen by an attacker (as discussed in Section 4.2).

On Wed, Aug 3, 2022 at 7:43 PM <[e-mail]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Adaptive DNS Discovery WG of the IETF.
>
>         Title           : Discovery of Designated Resolvers
>         Authors         : Tommy Pauly
>                           Eric Kinnear
>                           Christopher A. Wood
>                           Patrick McManus
>                           Tommy Jensen
>   Filename        : draft-ietf-add-ddr-09.txt
>   Pages           : 20
>   Date            : 2022-08-03
>
> Abstract:
>    This document defines Discovery of Designated Resolvers (DDR), a
>    mechanism for DNS clients to use DNS records to discover a resolver's
>    encrypted DNS configuration.  An encrypted DNS resolver discovered in
>    this manner is referred to as a "Designated Resolver".  This
>    mechanism can be used to move from unencrypted DNS to encrypted DNS
>    when only the IP address of a resolver is known.  This mechanism is
>    designed to be limited to cases where unencrypted DNS resolvers and
>    their designated resolvers are operated by the same entity or
>    cooperating entities.  It can also be used to discover support for
>    encrypted DNS protocols when the name of an encrypted DNS resolver is
>    known.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-add-ddr/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-add-ddr-09.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-add-ddr-09
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>