Draft: draft-ietf-add-ddr

Commentary: DISCUSS : CC See my discuss on draft - ietf - add - ddr-11 for my generic ADD DNR / DDR concerns 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 . Resolver that does not use a private or local IP address and can be verified using the mechanism described in Section 4.2 , it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in Section 4.2 . This seems to go against a lot of advise in the documents that networks must be treated independently . Also , the network wants you to use their designated resolver , so to say it is okay to use a totally different Designated Resolvers seems to violate the whole DNR / DDR architecture . This will also cause failure if there is split - DNS or internal - only data . Also , using " public IP " is not a good trustworthy method to prove that these IPs are truly the same Designated Resolver used by both networks . I can easily use an internal only zone with . IN A 8.8.8.8 and get a valid ACME'd certificate with SAN=. The user connecting to another network might now be switching from my private DNS on my stolen 8.8.8.8 IP to the real google DNS . 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 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 ) 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  DDR . 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 ? yields an IP address that was not presented in the Additional Answers section or ipv4hint or ipv6hint fields of the original SVCB query , the connection made to that IP address MUST pass the same TLS certificate checks before being allowed to replace a previously known and validated IP address for the same Designated Resolver name . How does the appearance of an ( unsigned ) Additional Answer entry convey any kind of real world trust / authentication ? In other words , why should it not ALWAYS pass the same TLS certificate checks ? is to use unencrypted DNS , why not just use it anyway ? use DDR to discover details about all supported encrypted DNS protocols . It 's a little odd to mention this as the DNR draft really tries hard to say to only use the network 's offered encrypted DNS servers , so this option is in conflict with the DNR draft . Unfortunately , all currently deployed software does not know this , so it will be very common that this happens . SHOULD treat as a locally served zone per [ RFC6303 ] Why is this not a MUST ? queries being dropped either maliciously or unintentionally , clients can re - send their SVCB queries periodically . I do n'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 . 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 can not 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 . 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 .   , 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 , would n't it fallback to the Unencrypted Resolver ? But now it may not ? So this becomes a denial of service then ? to cases where the Unencrypted Resolver and Designated Resolver have the same IP address . Based on earlier text , this should read " the same non - public IP address " . 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 ? Special - Use Domain Names ( SUDN ) registry established by [ RFC6761 ] . Why not pick As .local is already handled to not be forwarded by DNS forwarders . It would also not require an addition to SUDN . Even if someone was already using , it would not interfere with that usage because that usage would not be using SVCB records . 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 can not 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 does n'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 . as the protocol is mentioned throughout the document as interacting with this protocol . when accessing web content on a dual - stack network : A , AAAA , and HTTPS queries . Discovering a Designated Resolver as part of one of these queries , without having to add yet another query , minimizes the total number of queries clients send . I do n't understand this paragraph . Once clients can send SVCB queries for web content , they already have had to do all the DDR / DNR related queries , so I do n't understand the argument of " saving queries " ? Also , it is adding queries for a specific target , eg , and this can not be " saved " either ? What am I misunderstanding here ? provides provides -provides 
 We should reference Security Considerations , because if you do n't have any validation , an attacker can point you to any server they want ( someone other than the server you were configured with by DHCP , etc ) . 
 We can probably just remove this , not using it in implementations right now . 
 It 's already done by the major public resolvers , and there is an RFC to support this ( RFC 8738 ) . The IP address validation is clearly important and a matter of WG consensus . Hopefully , this will push adoption of RFC 8738 by more ACME services . 
 We can reference the DNR section . The MUST NOT should only apply to DDR , but does n't invalidate other ways of using the resolver . 
 If they are different , it can be a random attacker ( see security considerations ) . The client may also have other better options to fall back to . 
  , this should be simplified to say " even if you connect over a different IP address for any reason , still validate the original IP address " 
 There are definitely cases where the client can have directly selected their own resolver name , etc . We do n't have to use the network resolver . 
 Correct , and that 's why we need this document , and it was to the IANA section . 
 Sure , we can make this a MUST . 
 It makes the attacker 's job harder by requiring them to be persistent . Normal retransmission logic is fine too . 
 This is a direct outcome of the svcb - dns document . Spoofing SVCB should n't be enough to cause a DoS here , because we should continue to use the previously used encrypted DNS server while on this network ( even if you get a bad SVCB packet ) . 
 For the security reasons , I think this needs to stay as a MUST NOT . However , if you differentiate based on hostname + path , you can still differentiate , it just is n't a differentiation that can be discovered by IP address queries . 
 Yes , you 'd fall back to unencrypted resolution if you ca n't have a secure trusted connection for encrypted resolution . 
 Yes , but that part is SHOULD . Will fix . 
 I think that 's just opportunistic DoT / DoQ. That 's already specified . 
 .local is the SUDN for multicast DNS , but it is also squatted on by some internal networks . Following the patterns for , etc , .arpa is a much more appropriate name . This is what the group had consensus on years ago and has been deployed widely already . 
 I think we can say " as explained in RFC 8484 , do n't loop on the resolver name . " 
 Sure , that 's fine . 
 Yeah , this paragraph is old and can be removed . 
 Looks good ! Just silly editorial nits
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.
To avoid name lookup deadlock, clients that use Designated Resolvers
need to ensure that a specific Encrypted Resolver is not used for any
queries that are needed to resolve the name of the resolver itself or
to perform certificate revocation checks for the resolver, as
described in Section 10 of RFC8484.  Designated Resolvers need to
ensure this deadlock is avoidable as described in Section 10 of
RFC8484.
A client MAY additionally use a discovered Designated Resolver
without either of these methods, based on implementation-specific
policy or user input.  Details of such policy are out of scope of
this document.  Clients MUST NOT automatically use a Designated
Resolver without some sort of validation, such as the two methods
defined in this document or a future mechanism.
A client MAY additionally use a discovered Designated Resolver
without either of these methods, based on implementation-specific
policy or user input.  Details of such policy are out of scope of
this document.  Clients MUST NOT automatically use a Designated
Resolver without some sort of validation, such as the two methods
defined in this document or a future mechanism.  Use without
validation can allow an attacker to direct traffic to an Encrypted
Resolver that is unrelated to the original Unencrypted DNS Resolver,
as described in security.
If a client is configured with the same Unencrypted DNS Resolver IP
address on multiple different networks, a Designated Resolver that
has been discovered on one network SHOULD NOT be reused on any of the
other networks without repeating the discovery process for each
network.
However, if a given Unencrypted DNS Resolver designates a Designated
Resolver that does not use a private or local IP address and can be
verified using the mechanism described in verified, it MAY be used on
different network connections so long as the subsequent connections
over other networks can also be successfully verified using the
mechanism described in verified.  This is a tradeoff between
performance (by having no delay in establishing an encrypted DNS
connection on the new network) and functionality (if the Unencrypted
DNS Resolver intends to designate different Designated Resolvers
based on the network from which clients connect).
If a client is configured with the same Unencrypted DNS Resolver IP
address on multiple different networks, a Designated Resolver that
has been discovered on one network SHOULD NOT be reused on any of the
other networks without repeating the discovery process for each
network, since the same IP address may be used for different servers
on the different networks.
If these checks fail, the client MUST NOT automatically use the
discovered Designated Resolver.  Additionally, the client SHOULD
suppress any further queries for Designated Resolvers using this
Unencrypted DNS Resolver for the length of time indicated by the SVCB
record's Time to Live (TTL) in order to avoid excessive queries that
will lead to further failed validations.
If these checks fail, the client MUST NOT automatically use the
discovered Designated Resolver if this designation was only
discovered via a "_dns.resolver.arpa." query (if the designation was
advertised directly by the network as described in dnr-interaction,
the server can still be used).  Additionally, the client SHOULD
suppress any further queries for Designated Resolvers using this
Unencrypted DNS Resolver for the length of time indicated by the SVCB
record's Time to Live (TTL) in order to avoid excessive queries that
will lead to further failed validations.
If the Designated Resolver and the Unencrypted DNS Resolver share an
IP address, clients MAY choose to opportunistically use the
Designated Resolver even without this certificate check
(opportunistic).
If resolving the name of a Designated Resolver from an SVCB record
yields an IP address that was not presented in the Additional Answers
section or ipv4hint or ipv6hint fields of the original SVCB query,
the connection made to that IP address MUST pass the same TLS
certificate checks before being allowed to replace a previously known
and validated IP address for the same Designated Resolver name.
If the Designated Resolver and the Unencrypted DNS Resolver share an
IP address, clients MAY choose to opportunistically use the
Designated Resolver even without this certificate check
(opportunistic).  If the IP address is not shared, opportunistic use
allows for attackers to redirect queries to an unrelated Encrypted
Resolver, as described in security.
Connections to a Designated Resolver can use a different IP address
than the IP address of the Unencrypted DNS Resolver, such as if the
process of resolving the SVCB service yields additional addresses.
Even when a different IP address is used for the connection, the TLS
certificate checks described in this section still apply for the
original IP address of the Unencrypted DNS Resolver.
DNS resolvers that support DDR by responding to queries for
_dns.resolver.arpa SHOULD treat resolver.arpa as a locally served
zone per RFC6303.  In practice, this means that resolvers SHOULD
respond to queries of any type other than SVCB for _dns.resolver.arpa
with NODATA and queries of any type for any domain name under
resolver.arpa with NODATA.
DNS resolvers that support DDR by responding to queries for
_dns.resolver.arpa MUST treat resolver.arpa as a locally served zone
per RFC6303.  In practice, this means that resolvers SHOULD respond
to queries of any type other than SVCB for _dns.resolver.arpa with
NODATA and queries of any type for any domain name under
resolver.arpa with NODATA.
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,
unless verification of the resolver fails.
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.  For DDR, clients need to validate a Designated Resolver
using a connection to the server before trusting it, so attackers
that can block these connections can prevent clients from switching
to use encrypted DNS.
Unencrypted DNS Resolver, clients applying Verified Discovery
(verified) MUST validate that the IP address of the Unencrypted DNS
Resolver is covered by the SubjectAlternativeName of the Designated
Resolver's TLS certificate.  If that validation fails, the client
MUST NOT automatically use the discovered Designated Resolver.
If the IP address of a Designated Resolver differs from that of an
Unencrypted DNS Resolver, clients applying Verified Discovery
(verified) MUST validate that the IP address of the Unencrypted DNS
Resolver is covered by the SubjectAlternativeName of the Designated
Resolver's TLS certificate.  If that validation fails, the client
MUST NOT automatically use the discovered Designated Resolver.
Clients using Opportunistic Discovery (opportunistic) MUST be limited
to cases where the Unencrypted DNS Resolver and Designated Resolver
have the same IP address.  Clients which do not follow Opportunistic
Discovery (opportunistic) and instead try to connect without first
checking for a designation run the possible risk of being intercepted
by an attacker hosting an Encrypted DNS Resolver on an IP address of
an Unencrypted DNS Resolver where the attacker has failed to gain
control of the Unencrypted DNS Resolver.
Clients using Opportunistic Discovery (opportunistic) MUST be limited
to cases where the Unencrypted DNS Resolver and Designated Resolver
have the same IP address, which SHOULD be a private or local IP
address.  Clients which do not follow Opportunistic Discovery
(opportunistic) and instead try to connect without first checking for
a designation run the possible risk of being intercepted by an
attacker hosting an Encrypted DNS Resolver on an IP address of an
Unencrypted DNS Resolver where the attacker has failed to gain
control of the Unencrypted DNS Resolver.