Draft: draft-ietf-add-ddr

Commentary: This review does NOT close the issue ; it only addresses the " easier " items . The harder , normative challenging comments may be tackled together with overlapping feedback from other reviewers such as  . 
 Summary : Has issues to address before publication as a Proposed Standard RFC ( Note : I reviewed -07 , and noticed -08 while entering this review . I 've read the diffs , and believe all the below to still be relevant ) . Issues : RFC 6761 requires explicit discussion of seven categories of consumers of a new SUDN . This document does not yet provide that discussion . There 's a lack of discussion of issues around certificate revocation throughout the document . The end of section 4.1.1 , for example , cuts off an mitigation opportunity should control of a certificate used by the Designated Resolver be lost . Please add an explanation for why the requirement in the last sentence of the first paragraph of 4.2 exists . As written , it seems out of context , and underspecified ( which SVBC result , obtained when , should the client consider the TTL from ? ) . The discussion of providing differentiated behavior over unencrypted DNS is good to call out , but needs more depth . There are many other fields an attacker might modify , even outside the DNS part of the datagram ( say , the source IP address ) that could give the attacker an advantage if the returned results varied . Nits : In the introduction , please reconsider " claims ownership over the IP addresses " . It would be better to simply say " contains the IP addresses in the SubjectAltName . There is tension between the normative SHOULD NOT and SHOULD in the first paragraph of 4.1.1 and the SHOULD in the first paragraph of 4.2 . Please clarify the wording in one place or the other so that an implementer is n't forced to violate one of those normative requirements to satisfy the other . The last sentence of the first paragraph of 4.3 is imprecise . It would address my discomfort to replace " can not be confirmed " with " can not be safely confirmed " , or add a pointer to a description somewhere else about why trying to include such addresses in a certificate is an unworkable idea . At the end of the second paragraph of 4.3 , consider future protocols that might use something other than TLS as the security layer . The sentence as is takes a shortcut past the point your are really trying to make . The use of SHOULD in the second paragraph of section 5 is strange . Do you mean " are expected to be " ? The other side of this coin ( that records are NOT expected to be present ) is n't obvious to find in section 4 . Consider explicitly calling out what the implementation MUST do if the validation in the 4th paragraph of section 7 fails . ( Feel free to ignore this , but ): At the 5th paragraph of section 7 , consider discussing the risks of an operator running an Unencrypted Resolver at a given IP and not running a Designated Resolver there . This adds an attack point for an adversary to gain enough access to run their own Designated Resolver there , even if they ca n't gain enough privilege to affect the Unencrypted Resolver . Micro - Nits : Section 3 3rd to last paragraph : s / use others records / use other records/ 
 Major issues already addressed in other PRs , and nits addressed in
Both of these approaches allow clients to confirm that a discovered
Encrypted Resolver is designated by the originally provisioned
resolver.  "Designated" in this context means that the resolvers are
operated by the same entity or cooperating entities; for example, the
resolvers are accessible on the same IP address, or there is a
certificate that claims ownership over the IP address for the
original designating resolver.
Both of these approaches allow clients to confirm that a discovered
Encrypted Resolver is designated by the originally provisioned
resolver.  "Designated" in this context means that the resolvers are
operated by the same entity or cooperating entities; for example, the
resolvers are accessible on the same IP address, or there is a
certificate that contains the IP address for the original designating
resolver.
There are situations where Verified Discovery of encrypted DNS
configuration over unencrypted DNS is not possible.  This includes
Unencrypted Resolvers on private IP addresses RFC1918, Unique Local
Addresses (ULAs) RFC4193, and Link Local Addresses RFC3927 RFC4291,
whose identity cannot be confirmed using TLS certificates under most
conditions.
There are situations where Verified Discovery of encrypted DNS
configuration over unencrypted DNS is not possible.  This includes
Unencrypted Resolvers on private IP addresses RFC1918, Unique Local
Addresses (ULAs) RFC4193, and Link Local Addresses RFC3927 RFC4291,
whose identity cannot be safely confirmed using TLS certificates
under most conditions.
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.  Opportunistic Privacy similarly
applies to DoQ RFC9250.  A client MAY use information from the SVCB
record for "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 private or
local IP addresses.  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.  Opportunistic Privacy similarly
applies to DoQ RFC9250.  A client MAY use information from the SVCB
record for "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 private or
local IP addresses.
If the IP address of a Designated Resolver differs from that of an
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.
Clients using Opportunistic Discovery (opportunistic) MUST be limited
to cases where the Unencrypted Resolver and Designated Resolver have
the same IP address.
If the IP address of a Designated Resolver differs from that of an
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.  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 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.