[Add] Paul Wouters' Abstain on draft-ietf-add-ddr-10: (with COMMENT)
Paul Wouters via Datatracker <noreply@ietf.org> Mon, 08 August 2022 21:41 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: add@ietf.org
Delivered-To: add@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9D9C15A724; Mon, 8 Aug 2022 14:41:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-add-ddr@ietf.org, add-chairs@ietf.org, add@ietf.org, Andrew.Campling@419.Consulting, Andrew.Campling@419.Consulting
X-Test-IDTracker: no
X-IETF-IDTracker: 8.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Paul Wouters <paul.wouters@aiven.io>
Message-ID: <165999487183.58655.2353058466657142866@ietfa.amsl.com>
Date: Mon, 08 Aug 2022 14:41:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/3VAiAhzF-21VCtd8T5iYhJGEZ00>
Subject: [Add] Paul Wouters' Abstain on draft-ietf-add-ddr-10: (with COMMENT)
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2022 21:41:11 -0000
Paul Wouters has entered the following ballot position for draft-ietf-add-ddr-10: Abstain 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # SEC AD comments for {draft-ietf-add-ddr-10} CC @paulwouters ## Abstain I find the set of documents in the ADD WG incomplete from a security point of view. This is due to client policy being purposefully left out of the WG charter, which is unfixable at this point in the process. I will therefore abstain so that these documents can be published. Hopefully, a BoF/WG in the future will attempt to address this security problem. ## unresolved DISCUSS items Below follows my specific old DISCUSS items that were not addressed. ### 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. ### 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. Note: this was updated in -10 to match the DNR, but it matches the weak method of DHCP/RA, so that if the TLS checks fail, it might still end up being used as "Verified Discovery". ### 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? ### Opportunistic Discovery has the same "same IP" issue. As the alternative is to use unencrypted DNS, why not just use it anyway? Note: the text was changed but the issue remains ### 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. Note: Also, why is this not a MUST NOT? ### 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 ? ### 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? ## Unresolved 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.
- [Add] Paul Wouters' Abstain on draft-ietf-add-ddr… Paul Wouters via Datatracker