Draft: draft-ietf-add-ddr

Commentary: 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 for this value . Clients can either send the IP address or the ServiceMode TargetName 
 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 . 
 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 , 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 . is right we should clarify in the text about how to handle aliases . In fact , 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 the addition of a second reference identity is a mistake . But I was not asking about that . You ca n'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 does n'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 : first non - attr - leaf TargetName in the chain leading to the ServiceMode SVCB RR . TargetName in ServiceMode SVCB RR . The DNR draft has a much better approach here : 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 can not be influenced by the SVCB record contents . I think we need a change to both drafts . EDIT : See , which distinguishes the " binding authority " from the " authentication name " . This would allow DDR to say something like 
 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 would n'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 does n'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 – either to explain the resolution ( if it ’s resolved by then ) – or to explain the issue and the different sides of the discussion . 
 Your message got a bit mangled , but I agree that this would be worth discussing as a group . 
 I was n’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 . 
 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. , " " and " " and the CDN just steers based on Host : header . So what I do is I stand up a DoH server on " " that produces lying responses . Then I arrange for your SVCB record to have the name " " and I have persuaded the client to accept responses from my invalid server . 
 One suggestion , but otherwise looking good .
A resolver, presumably an Encrypted Resolver, designated by
another resolver for use in its own place.  This designation can
be authenticated with TLS certificates.
When a client discovers Designated Resolvers, it learns information
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.
When a client discovers Designated Resolvers, it learns information
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.
Verified Discovery verified, for when a TLS certificate can be
used to validate the resolver's identity.
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).
Verified Discovery is a mechanism that allows automatic use of a
Designated Resolver that supports DNS encryption that performs a TLS
handshake.
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).
Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as
a mode in which clients do not validate the name of the resolver
presented in the certificate.  A client MAY use information from the
SVCB record for "dns://resolver.arpa" with this "opportunistic"
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
of the Unencrypted Resolver.  This approach can be used for any
encrypted DNS protocol that uses TLS.
Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as
a mode in which clients do not validate the name of the resolver
presented in the certificate.  A client MAY use information from the
SVCB record for "dns://resolver.arpa" with this "opportunistic"
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
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.
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".
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".
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
addresses.
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
the SVCB record when it cannot be verified.
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
addresses.
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.
The constraints on the use of Designated Resolvers specified here
apply specifically to the automatic discovery mechanisms defined in
this document, which are referred to as Verified Discovery and
Opportunistic Discovery.  Clients MAY use some other mechanism to
verify and use Designated Resolvers discovered using the DNS SVCB
record.  However, use of such an alternate mechanism needs to take
into account the attack scenarios detailed here.