Change:
Remove text about extra cert checks, just focus on the IP address Add considerations about server name handling. Server must accept IP address for SNI and URI host. Clients must not use URL for this value. Clients can either send the IP address or the ServiceMode TargetName
NAME this removes checking for both the name and the IP address. The text about checking the name is for when the client started with a name, not an IP address.
NAME please take another look!
When this says "the domain name (from the SVCB answer)", what does it refer to? Does this refer to the TargetName of a SVCB record? If so, which TargetName? If I query for SVCB records at URL, I might get an arbitrary number of AliasMode SVCB RRs, which might each lead to some number of other AliasMode SVCB RRs on the way to a ServiceMode SVCB RR. That might be a lot of options.
I continue to believe that this entire concept should be removed from the draft. The IP address of the Unencrypted Resolver is the only securely sourced reference identity, and it is the only identity that should be required in the certificate.
The name that’s used in the HTTP request as the authority and the TLS SNI really should be in the certificate :) we’ve covered this before, and I see no reason that these connections would have a strange exception to not expect a match between the DoH name and the certificate. NAME is right we should clarify in the text about how to handle aliases. In fact, NAME should this be in the reference doc about DNS SVCB instead of here? It describes how to construct the DoH URI, and the answer here needs the be the same as the DoH URI’s hostname.
To be clear, I agree with NAME the addition of a second reference identity is a mistake. But I was not asking about that. You can't rely on DNS SVCB to solve this problem, because you invented this particular problem. DNS SVCB does the sensible thing and assumes that the client will not allow its opinions regarding a reference identity to be influenced by something as dangerous as DNS (see also: mistakes of MX). As this document doesn't hold to that principle, it has to deal with the consequences of that choice. At a minimum, that means deciding on exactly how your new reference identity is determined. I think your options basically reduce to one of: The first non-attr-leaf TargetName in the chain leading to the ServiceMode SVCB RR. The TargetName in ServiceMode SVCB RR. The DNR draft has a much better approach here: As we're relying on DHCP/RA for "trustworthy" configuration, have that system provide a name.
Yes, and the authority is the IP address. When using DDR with 9.9.9.9, the DoH URI should be , regardless of the actual transport IP. That draft currently says: by combining the prefix "https://", the service name, the port from the "port" key if present, and the "dohpath" value and transport establishment. This name is the hostname used to construct the original SVCB query, and cannot be influenced by the SVCB record contents. I think we need a change to both drafts. EDIT: See URL, which distinguishes the "binding authority" from the "authentication name". This would allow DDR to say something like
NAME thanks for the change in the SVCB-DNS draft. That certainly helps make this more consistent. With that change, then we no longer need to have any special case in DDR for making sure that both the address and the name used in the HTTP authority are the covered in the cert, since they'll be the same.
I'm sorry, what? The WG soundly rejected IP address hostnames as a requirement back in RESINFO days. This is a full 180 pivot. I see reviewing the notes that no consensus was gained during IETF 109 on the topic of "why do we have two identities?". I think it's fair to say DDR only cares about the source IP address. I would expect in practice that most clients will end up confirming the hostname as well because who would do that for all HTTPS connections except DDR ones, but it certainly is a HTTPS/TLS requirement and not a DDR requirement. I suggest we remove the hostname requirement. I strongly oppose requiring the hostname to equal the source IP address. It will likely make recursive resolver deployment a nightmare, and absolutely needs to be brought to the list before any text changes are made.
Going off of Tommy's point, another reason it would be incorrect to force the HTTP host or TLS SNI to be an address is that this wouldn't work for the "opportunistic" case, where the address is shared but not covered by the cert. So I think we should remove the line about checking the hostname in the cert, but also explain how to get the name from the SVCB record. Initially, the first name we get back in the chain sounds like the right answer.
In the same-IP opportunistic case, there is no certificate validation, so it doesn't matter what name (if any) is in the cert. Using the (local, private) IP address makes this unambiguous. Using the hostname makes this confusing: it suggests the existence of a reference identity where none exists.
This seems like a topic for NAME – either to explain the resolution (if it’s resolved by then) – or to explain the issue and the different sides of the discussion.
NAME Your message got a bit mangled, but I agree that this would be worth discussing as a group.
NAME I wasn’t suggesting anything about certificate validation. Rather, that for opportunistic mode, we should provide guidance about which hostname to use in the SNI and HTTP authority.
NAME NAME NAME to make this concrete, I wrote up what I was thinking in
Too follow up what I said in the meeting: What if you have a situation where a DoH server is co-located with a hosting system, e.g., "URL" and "URL" and the CDN just steers based on Host: header. So what I do is I stand up a DoH server on "URL" that produces lying responses. Then I arrange for your SVCB record to have the name "URL" and I have persuaded the client to accept responses from my invalid server.
One suggestion, but otherwise looking good.

Discussion:
A resolver, presumably an Encrypted Resolver, designated by another resolver for use in its own place.  This designation can <del> be authenticated with TLS certificates. </del> <ins> be verified with TLS certificates. </ins> A DNS resolver using any encrypted DNS transport.  This includes current mechanisms such as DoH and DoT as well as future

entity. When a client discovers Designated Resolvers, it learns information <del> such as the supported protocols, ports, and server name to use in certificate validation.  This information is provided in Service Binding (SVCB) records for DNS Servers.  The formatting of these records, including the DNS-unique parameters such as "dohpath", are defined by I-D.ietf-add-svcb-dns. </del> <ins> such as the supported protocols and ports.  This information is provided in Service Binding (SVCB) records for DNS Servers.  The formatting of these records, including the DNS-unique parameters such as "dohpath", are defined by I-D.ietf-add-svcb-dns. </ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net":

D.ietf-add-svcb-dns.  However, if any protocol does not involve some form of certificate validation, new validation mechanisms will need to be defined to support validating designation as defined in <del> authenticated. </del> <ins> verified. </ins> 4.

This document defines two preferred methods to automatically use Designated Resolvers: <del> Authenticated Discovery authenticated, for when a TLS certificate can be used to validate the resolver's identity. </del> <ins> Verified Discovery verified, for when a TLS certificate can be used to validate the resolver's identity. </ins> Opportunistic Discovery opportunistic, for when a resolver is accessed using a non-public IP address.

4.2. <del> Authenticated Discovery is a mechanism that allows automatic use of a </del> <ins> Verified Discovery is a mechanism that allows automatic use of a </ins> Designated Resolver that supports DNS encryption that performs a TLS handshake. <del> In order to be considered an authenticated Designated Resolver, the TLS certificate presented by the Designated Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the designating Unencrypted Resolver within the SubjectAlternativeName certificate field.  The client MUST check the SubjectAlternativeName field for both the Unencrypted Resolver's IP address and the advertised name of the Designated Resolver.  If the certificate can be validated, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the Unencrypted Resolver.  If the Designated Resolver has a different IP address than the Unencrypted Resolver and the TLS certificate does not cover the Unencrypted Resolver address, the client MUST NOT automatically use the discovered Designated Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record's Time to Live (TTL). </del> <ins> In order to be considered a verified Designated Resolver, the TLS certificate presented by the Designated Resolver MUST contain the IP address of the designating Unencrypted Resolver in a subjectAltName extension.  If the certificate can be validated, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the Unencrypted Resolver.  If the Designated Resolver has a different IP address than the Unencrypted Resolver and the TLS certificate does not cover the Unencrypted Resolver address, the client MUST NOT automatically use the discovered Designated Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record's Time to Live (TTL). </ins> If the Designated Resolver and the Unencrypted Resolver share an IP address, clients MAY choose to opportunistically use the Designated

4.3. <del> There are situations where authenticated discovery of encrypted DNS </del> <ins> There are situations where Verified Discovery of encrypted DNS </ins> configuration over unencrypted DNS is not possible.  This includes Unencrypted Resolvers on non-public IP addresses such as those defined in RFC1918 whose identity cannot be confirmed using TLS

approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address <del> of the Unencrypted Resolver.  This approach can be used for any encrypted DNS protocol that uses TLS. </del> <ins> of the Unencrypted Resolver.  Clients SHOULD use this mode only for resolvers using non-public IP addresses.  This approach can be used for any encrypted DNS protocol that uses TLS. </ins> 5.

indicate that "resolver.example.com" supports both DoH and DoT, and that the DoH server indicates a higher priority than the DoT server. <del> Often, the various supported encrypted DNS protocols will be accessible using the same hostname.  In the example above, both DoH and DoT use the name "resolver.example.com" for their TLS certificates.  If a deployment uses a different hostname for one protocol, but still wants clients to treat both DNS servers as designated, the TLS certificates MUST include both names in the SubjectAlternativeName fields.  Note that this name verification is not related to the DNS resolver that provided the SVCB answer. For example, being able to discover a Designated Resolver for a known Encrypted Resolver is useful when a client has a DoT configuration for "foo.resolver.example.com" but is on a network that blocks DoT traffic.  The client can still send a query to any other accessible resolver (either the local network resolver or an accessible DoH server) to discover if there is a designated DoH server for "foo.resolver.example.com". </del> <ins> Clients MUST validate that for any Encrypted Resolver discovered using a known resolver name, the TLS certificate of the resolver contains the known name in a subjectAltName extension.  In the example above, this means that both servers need to have certificates that cover the name "resolver.example.com".  Often, the various supported encrypted DNS protocols will be specified such that the SVCB TargetName matches the known name, as is true in the example above.  However, even when the TargetName is different (for example, if the DoH server had a TargetName of "doh.example.com"), the clients still check for the original known resolver name in the certificate. Note that this resolver validation is not related to the DNS resolver that provided the SVCB answer. As another example, being able to discover a Designated Resolver for a known Encrypted Resolver is useful when a client has a DoT configuration for "foo.resolver.example.com" but is on a network that blocks DoT traffic.  The client can still send a query to any other accessible resolver (either the local network resolver or an accessible DoH server) to discover if there is a designated DoH server for "foo.resolver.example.com". </ins> 6.

Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR by a resolver does not communicate a requirement for clients to use <del> the SVCB record when it cannot be authenticated. </del> <ins> the SVCB record when it cannot be verified. </ins> 6.2. <del> Resolver owners that support authenticated discovery will need to list valid referring IP addresses in their TLS certificates.  This may pose challenges for resolvers with a large number of referring IP </del> <ins> Resolver owners that support Verified Discovery will need to list valid referring IP addresses in their TLS certificates.  This may pose challenges for resolvers with a large number of referring IP </ins> addresses. <ins> 6.3. Clients MUST NOT use "resolver.arpa" as the server name either in the TLS Server Name Indication (SNI) (RFC8446) for DoT or DoH connections, or in the URI host for DoH requests. When performing discovery using resolver IP addresses, clients MUST use the IP address as the URI host for DoH requests. Note that since IP addresses are not supported by default in the TLS SNI, resolvers that support discovery using IP addresses will need to be configured to present the appropriate TLS certificate when no SNI is present for both DoT and DoH. </ins> 7. Since clients can receive DNS SVCB answers over unencrypted DNS, on-

user queries without the knowledge of the client or network. If the IP address of a Designated Resolver differs from that of an <del> Unencrypted Resolver, clients applying Authenicated Discovery (authenticated) MUST validate that the IP address of the Unencrypted Resolver is covered by the SubjectAlternativeName of the Designated Resolver's TLS certificate. </del> <ins> Unencrypted Resolver, clients applying Verified Discovery (verified) MUST validate that the IP address of the Unencrypted Resolver is covered by the SubjectAlternativeName of the Designated Resolver's TLS certificate. </ins> Clients using Opportunistic Discovery (opportunistic) MUST be limited to cases where the Unencrypted Resolver and Designated Resolver have the same IP address. <del> The constraints on validation of Designated Resolvers specified here </del> <ins> The constraints on the use of Designated Resolvers specified here </ins> apply specifically to the automatic discovery mechanisms defined in <del> this document, which are referred to as Authenticated Discovery and </del> <ins> this document, which are referred to as Verified Discovery and </ins> Opportunistic Discovery.  Clients MAY use some other mechanism to <del> validate and use Designated Resolvers discovered using the DNS SVCB </del> <ins> verify and use Designated Resolvers discovered using the DNS SVCB </ins> record.  However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here.