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

[Ben Schwartz <[e-mail]>]

Thanks, I think this draft is a good starting point and close to adoption-ready.  I do still see some issues:

Section 3.1.1:

"Using this method, 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." -> SVCB records don't indicate a domain name in the sense used here.  The SVCB TargetName is similar to a CNAME target: it does not alter the TLS handshake in any way.  Thus, the client can follow any SVCB record, but the SVCB record does not affect the TLS SNI or the certificate validation procedure.

"The destination server MAY use delegated credentials [RFC9345]." -> This seems to imply that any client who could somehow end up pointed to this destination server MUST offer support for delegated credentials.  Otherwise, current DDR clients that don't support delegated credentials would run into a handshake failure.  We need to be clearer about the expectations about client support for delegated credentials.

Section 3.1.2:

"When clients use Strict Origin redirection discovery with a DDR discovered resolver, the only difference is that the destination server it was redirected to MUST be able to claim the IP address of the previous server in its SAN field." -> I'm not sure that's the only​ difference.  There's also the problem that you can't put an IP address in the TLS SNI, so the SNI has to be omitted, which means any covered IP addresses must all share a single certificate.

Section 3.4:

"Clients SHOULD however cap this value to some minimum value at their discretion to avoid frequent redirection checking when latency plus an incidentally low TTL along the chain results in near-zero effective TTLs." -> This is recommending a form of TTL stretching.  I think a more formally correct approach would be to ignore redirections whose TTL falls below the client's configured minimum.

--Ben
________________________________
From: Add <[e-mail]> on behalf of Tommy Jensen <Jensen.Thomas=[e-mail]>
Sent: Monday, March 4, 2024 1:21 PM
To: [e-mail] <[e-mail]>
Cc: Corey Mosher <[e-mail]>; John Todd <[e-mail]>
Subject: [Add] Fw: [EXTERNAL] New Version Notification for draft-jt-add-dns-server-redirection-03.txt

Good day add WG, We have submitted the -03 of EDSR for IETF 119 discussion. The only major change (and it's a big one) is to remove the controversial SOR mode, so that the draft only supports redirections to other servers with the same domain
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
Good day add WG,

We have submitted the -03 of EDSR for IETF 119 discussion. The only major change (and it's a big one) is to remove the controversial SOR mode, so that the draft only supports redirections to other servers with the same domain name. This addresses what we believe to be the main pushback on the draft.

Let us know what you think of the new text.


Thanks,

Tommy


________________________________
From: [e-mail] <[e-mail]>
Sent: Monday, March 4, 2024 10:13 AM
To: C. Mosher <[e-mail]>; J. Todd <[e-mail]>; Tommy Jensen <[e-mail]>; Corey Mosher <[e-mail]>; John Todd <[e-mail]>; Tommy Jensen <[e-mail]>
Subject: [EXTERNAL] New Version Notification for draft-jt-add-dns-server-redirection-03.txt

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

Name:     draft-jt-add-dns-server-redirection
Revision: 03
Title:    Handling Encrypted DNS Server Redirection
Date:     2024-03-04
Group:    add
Pages:    12
URL:    https://www.ietf.org/archive/id/draft-jt-add-dns-server-redirection-03.txt<https://www.ietf.org/archive/id/draft-jt-add-dns-server-redirection-03.txt>
Status: https://datatracker.ietf.org/doc/draft-jt-add-dns-server-redirection/<https://datatracker.ietf.org/doc/draft-jt-add-dns-server-redirection/>
HTML:    https://www.ietf.org/archive/id/draft-jt-add-dns-server-redirection-03.html<https://www.ietf.org/archive/id/draft-jt-add-dns-server-redirection-03.html>
HTMLized: https://datatracker.ietf.org/doc/html/draft-jt-add-dns-server-redirection<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-03<https://author-tools.ietf.org/iddiff?url2=draft-jt-add-dns-server-redirection-03>

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