[Add] Paul Wouters' Discuss on draft-ietf-add-ddr-08: (with DISCUSS)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-add-ddr-08: 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-ddr/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# SEC AD comments for {draft-ietf-add-ddr-08}
CC @paulwouters

## Discuss

See my discuss on draft-ietf-add-ddr-11 for my generic ADD DNR/DDR concerns

###

   Clients MUST NOT automatically use a Designated
   Resolver without some sort of validation

Why not? What is the alternative? Using unencrypted DNS to the party that
told you how and where to contact these (unvalidated) Designated Resolvers.

###

   However, if a given Unencrypted Resolver designates a Designated
   Resolver that does not use a private or local IP address and can be
   verified using the mechanism described in Section 4.2, it MAY be used
   on different network connections so long as the subsequent
   connections over other networks can also be successfully verified
   using the mechanism described in Section 4.2.

This seems to go against a lot of advise in the documents that networks must
be treated independently. Also, the network _wants_ you to use their designated
resolver, so to say it is okay to use a totally different Designated Resolvers
seems to violate the whole DNR/DDR architecture.

This will also cause failure if there is split-DNS or internal-only data.

Also, using "public IP" is not a good trustworthy method to prove that these
IPs are truly the same Designated Resolver used by both networks. I can easily
use an internal only zone with dns.nohats.ca. IN A 8.8.8.8 and get a valid ACME'd
certificate with SAN=dns.nohats.ca. The user connecting to another network might
now be switching from my private DNS on my stolen 8.8.8.8 IP to the real google DNS.

###

      2.  The client MUST verify that the certificate contains the IP
       address of the designating Unencrypted Resolver in a
       subjectAltName extension.

How feasible is it to get a certificate with SAN=ip from one of the generally
accepted root store CA's? Can you give me one example where I can get a certificate
for nssec.nohats.ca with SAN=193.110.157.123 ?  I do not think this is currently
possible or easy. If I am right, that means all of Section 4.2 is wishful thinking
and not realistic to get rolled out. (I know we can see the cert for 1.1.1.1, so it
is possible, but I know of no ACME supported CA that issues these)

###

   If these checks fail, the client MUST NOT automatically use the
   discovered Designated Resolver.

This creates a strange policy when compared to DNR where if you get a DHCP or RA
for the Designated Resolver, which is also not validatable, that you do end up using it?
And section 6.5 states DNR trumps DDR.

###

   If the Designated Resolver and the Unencrypted Resolver share an IP
   address, clients MAY choose to opportunistically use the Designated
   Resolver even without this certificate check (Section 4.3).

Why only when the IP is the same? Why not for when the IP is different?
What's to lose, since the only fallback option is stick to using the
unencrypted resolver?

###

   If resolving the name of a Designated Resolver from an SVCB record
   yields an IP address that was not presented in the Additional Answers
   section or ipv4hint or ipv6hint fields of the original SVCB query,
   the connection made to that IP address MUST pass the same TLS
   certificate checks before being allowed to replace a previously known
   and validated IP address for the same Designated Resolver name.

How does the appearance of an (unsigned) Additional Answer entry convey
any kind of real world trust/authentication? In other words, why should
it not ALWAYS pass the same TLS certificate checks ?

###

Opportunistic Discovery has the same "same IP" issue. As the alternative
is to use unencrypted DNS, why not just use it anyway?

###

   A DNS client that already knows the name of an Encrypted Resolver can
   use DDR to discover details about all supported encrypted DNS
   protocols.

It's a little odd to mention this as the DNR draft really tries hard to
say to only use the network's offered encrypted DNS servers, so this
option is in conflict with the DNR draft.

###

   A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" upstream.

Unfortunately, all currently deployed software does not know this, so it will
be very common that this happens.

##

   DNS resolvers that support DDR by responding to queries for
   _dns.resolver.arpa SHOULD treat resolver.arpa as a locally served
   zone per [RFC6303]

Why is this not a MUST ?

###

   To limit the impact of discovery
   queries being dropped either maliciously or unintentionally, clients
   can re-send their SVCB queries periodically.

I don't see how this would improve security for the client. It also mixes
up behaviour of proper DNS clients that have their own retransmit logic
for if they get no answer.

###

   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, and recommends that clients prevent it by switching to SVCB-
   reliant behavior once SVCB resolution does succeed.  For DDR, this
   means that once a client discovers a compatible Designated Resolver,
   it SHOULD NOT use unencrypted DNS until the SVCB record expires

I wonder which attacker can block encrypted DNS connections but not spoof
(or block!) an unsigned SVCB record to the local client? And even if that is the case,
this would be a denial of service attack if the DNS client cannot fallback
to unencrypted DNS. Spoofing an SVCB to a bogus IP with an SVCB TTL of a few
hours would be a very cheap 1 packet attack to keep the DNS client down for
hours. This seems dangerous to implement.

###

   DoH resolvers that allow discovery using DNS SVCB answers over
   unencrypted DNS MUST NOT provide differentiated behavior based on the
   HTTP path alone, since an attacker could modify the "dohpath"
   parameter.  For example, if a DoH resolver provides provides a
   filtering service for one URI path, and a non-filtered service for
   another URI path, [...]

It seems likely that this advise will get ignored a lot, eg by people
who have limited public IPs to use to spin up a DoH server, or who have
to pay-per-IP. This advise seems more appropriate for local private IP
DoH servers. So I would change this MUST NOT to SHOULD NOT for that reason.

###

   If the IP address of a Designated Resolver differs from that of an
   Unencrypted Resolver, clients applying Verified Discovery
   (Section 4.2) MUST validate that the IP address of the Unencrypted
   Resolver is covered by the SubjectAlternativeName of the Designated
   Resolver's TLS certificate.

How would one obtain such a certificate via ACME? Since on the IP of the
unencrypted resolver, there would be no HTTP server running? Additionally,
if the client notices a failed verification of the Designated Resolver's
TLS certificate, wouldn't it fallback to the Unencrypted Resolver? But now
it may not? So this becomes a denial of service then ?

###

   Clients using Opportunistic Discovery (Section 4.3) MUST be limited
   to cases where the Unencrypted Resolver and Designated Resolver have
   the same IP address.

Based on earlier text, this should read "the same non-public IP address".

###

I kind of miss the mode of where there is no indication of DDR or DNR, and
you use "unilateral probing" (draft-ietf-dprive-unilateral-probing) to just
connect to the DoT or DoQ ports of the Unencrypted Resolver and see if you
get anything back. It might be unauthenticated TLS but better than port 53?

###

   This document calls for the addition of "resolver.arpa" to the
   Special-Use Domain Names (SUDN) registry established by [RFC6761].

Why not pick resolver.local? As .local is already handled to not be forwarded
by DNS forwarders. It would also not require an addition to SUDN. Even if
someone was already using resolver.local, it would not interfere with that usage
because that usage would not be using SVCB records.

## Comments

###

section 3

   To avoid name lookup deadlock, Designated Resolvers SHOULD follow the
   guidance in Section 10 of [RFC8484] regarding the avoidance of DNS-
   based references that block the completion of the TLS handshake.

I find that reference to list more the issues than solutions that can be followed.
The solution to use another DoH server is not really appropriate in most cases
The client's other interface likely resides on other networks where its private
DoH server cannot resolve the name of another network's private DoH server. It is
also not easy to get an IP based certificate (eg SAN=ip) that is accepted by general
webpki root stores. And things like OCSP stapling doesn't help if the target is
malicious - they just would omit the stapling that proves against its malicious use.
The only real advise usable from RFC8484 is "use the local unencrypted resolver to resolve
the encrypted resolver". Might as well say that and remove the 8484 reference.

###

I would argue that I-D.ietf-add-dnr is not an informative but normative reference,
as the protocol is mentioned throughout the document as interacting with this protocol.

###

      Clients that support SVCB will generally send out three queries
      when accessing web content on a dual-stack network: A, AAAA, and
      HTTPS queries.  Discovering a Designated Resolver as part of one
      of these queries, without having to add yet another query,
      minimizes the total number of queries clients send.

I don't understand this paragraph. Once clients can send SVCB queries for
web content, they already have had to do all the DDR/DNR related queries,
so I don't understand the argument of "saving queries" ? Also, it is
adding queries for a specific target, eg resolver.arpa, and this cannot
be "saved" either? What am I misunderstanding here?

###

NITS

provides provides -> provides