Re: [Add] [EXTERNAL] New Version Notification for draft-jt-add-dns-server-redirection-02.txt

Thanks for this revision.  I think the separation between Strict and Overlapping modes is helpful for reasoning about the behavior, and the Overlapping mode is a clever approach to inter-origin authorization.

I'm pretty sure that Overlapping mode still doesn't achieve the intended security property.  From a formal security perspective, it seems there's an assumption that the adversary and victim never share control of any domain.  That would a bit weird today, but if we are imagining an international federated resolver network (as has been discussed in relation to this draft) then it's actually plausible.

Ultimately, this step seems like a very complicated workaround for DNS cache poisoning vulnerabilities, and I think the right solution is to simply remove those vulnerabilities.  That could be done by mandating DNSSEC (on the zone and at the resolver; no need for a validating stub) or by moving "edsr-domain" into a poisoning-resistant channel like EDNS.

Some more detailed notes:

Section 3.1.1:

"if the returned SVCB record indicates a server with a different domain name than the current encrypted DNS connection, the redirection MUST NOT be followed by the client".

Could you clarify?  Do you mean "If TargetName is not the same as the DNS server's hostname"?  That restriction would seem to preclude any redirection.  Maybe you mean "if the returned SVCB record leads the user to a server that cannot prove ownership of the DNS server's hostname (e.g., via a valid X.509 certificate or TLSA record)"?  If so, please rephrase, and clearly specify the SNI and authentication name (ADN).

"The destination server MAY use delegated credentials"

Delegated credentials are not compatible with arbitrary existing Encrypted DNS clients, so this strikes me as unsafe.  What if a pre-existing client follows this SVCB record and doesn't support delegated credentials?  I can think of various possible solutions, but the one that was mentioned at the last meeting was to define a new "delegated-credentials" SvcParamKey and put "mandatory=delegated-credentials" in the SvcParams for these endpoints.

Section 3.1.2:

"The presence of the "edsr-domain" key indicates that the redirection is going to a server with a different domain name than the current server. For DoT and DoQ redirection, this is sufficient."

I think "edsr-domain" should indicate a new DNS server hostname, causing the client to resolve _dns.$NEW_HOSTNAME/SVCB.  Otherwise, you are trying to share SvcParams across two different hosts, resulting in a variety of potential conflicts.  (For example, consider how "ech" would behave.)

"edsr-apex-domain" seems to be misnamed (there's no guarantee about where the zone cuts fall).  Also, it seems like it could just be a wildcard in the edsr-domain SvcParam.  Also, I can't understand how it's supposed to work, so maybe you could add an example.

--Ben
________________________________
From: Add <add-bounces@ietf.org> on behalf of Tommy Jensen <Jensen.Thomas=40microsoft.com@dmarc.ietf.org>
Sent: Sunday, October 22, 2023 8:12 PM
To: ADD Mailing list <add@ietf.org>
Subject: [Add] FW: [EXTERNAL] New Version Notification for draft-jt-add-dns-server-redirection-02.txt

!-------------------------------------------------------------------|
  This Message Is From an External Sender

|-------------------------------------------------------------------!

Greetings ADD,

JT, Corey, and I have submitted a long-overdue revision to the EDSR proposal. It's a pretty heavy re-write, so we recommend you re-read it. Spoiler alert: the draft requires "strict origin" redirection support and recommends use of Delegated Credentials when the threat model calls for redirection to servers the DNS operator does not want to directly possess the name's private key.

The "redirect to another name" concept has been made into an alternative, totally optional mode called "overlapping origin" that requires each hop in the redirection to have a valid cert both for the new name and the previous name. The draft goes into detail about the scenario that would lead an implementor to use overlapping origin but describes why the scope is limited (general clients should never be expected to support it in the absence of client policy that dictates it's ok for some reason, such as expected name/server relationships).

Yes, I was that lazy and left TODOs instead of validating doc references. Consider that editorial work we will do after adoption; there should be no ambiguity about the docs being referenced for the purposes of adoption consideration.

Datatracker link: https://datatracker.ietf.org/doc/draft-jt-add-dns-server-redirection/

Thanks,
Tommy

-----Original Message-----
From: internet-drafts@ietf.org <internet-drafts@ietf.org>
Sent: Sunday, October 22, 2023 5:01 PM
To: C. Mosher <cmosher@gmail.com>; J. Todd <jtodd@quad9.net>; Tommy Jensen <Jensen.Thomas@microsoft.com>; Corey Mosher <cmosher@gmail.com>; John Todd <jtodd@quad9.net>; Tommy Jensen <Jensen.Thomas@microsoft.com>
Subject: [EXTERNAL] New Version Notification for draft-jt-add-dns-server-redirection-02.txt

A new version of Internet-Draft draft-jt-add-dns-server-redirection-02.txt has been successfully submitted by T. Jensen and posted to the IETF repository.

Name:     draft-jt-add-dns-server-redirection
Revision: 02
Title:    Handling Encrypted DNS Server Redirection
Date:     2023-10-22
Group:    Individual Submission
Pages:    15
URL:      https://www.ietf.org/archive/id/draft-jt-add-dns-server-redirection-02.txt
Status:   https://datatracker.ietf.org/doc/draft-jt-add-dns-server-redirection/
HTML:     https://www.ietf.org/archive/id/draft-jt-add-dns-server-redirection-02.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-jt-add-dns-server-redirection
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-jt-add-dns-server-redirection-02

Abstract:

   This document defines Encrypted DNS Server Redirection (EDSR), a
   mechanism for encrypted DNS servers to redirect clients to other
   encrypted DNS servers.  This enables dynamic routing to geo-located
   or otherwise more desirable encrypted DNS servers without modifying
   DNS client endpoint configurations or the use of anycast by the DNS
   server.

The IETF Secretariat

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add