Draft: draft-ietf-add-ddr

Commentary: The document was inconsistent , with the authenticated section saying same IP addresses MAY use opportunistic , but the opportunistic section saying the same IP address exception was for private IP addresses only . 
  to mention this is to address issue 
 From Eliot Lear : Can you explain the following statement ? and that IP address is a private address ( such as those defined in [ RFC1918 ] I ask because it appears that you are using private addresses as some sort of security property . I recommend against that , not least of which is that end systems that are likely to deploy this stuff will have a wide ranging mishmosh of addressing plans , and of course , private network addresses do n’t really have any positive security properties to speak of . The only aspect I can see is that one really has to be quite careful of including private network addresses in certificates . Of course , public trust anchors wo n’t allow it , but even private ones will have some difficulty . Your average bank might have multiple overlapping zones of trust - it ’s a pretty hairy scene . 
 The intent of that section is to say that " if you were going to send this local IP address unencrypted traffic anyway , using encryption to that same IP address is a net improvement to the threat model . " It certainly was not meant to imply that private addresses could be verified via the TLS cert SAN mechanism used for public addresses . I can try to rephrase this section to be more accurate . Please comment again if I missed the point . 
 In reviewing the opportunistic section , I see what you mean  . The need to use " private IP " as a feature is not necessary since same - IP opportunistic discovery is permitted whether the address is private or not . However , the draft conflicted on that point . I have a PR to remove the local IP address as a decision branch and make the draft consistent . 
 With the PR merged , I am closing this issue .
There are situations where authenticated discovery of encrypted DNS
configuration over unencrypted DNS is not possible.  This includes
Unencrypted Resolvers on non-public IP addresses whose identity
cannot be confirmed using TLS certificates.
There are situations where authenticated discovery of encrypted DNS
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
certificates.
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, and that IP address is a private address
(such as those defined in RFC1918).  This approach can be used for
DoT or DoH.
If the IP addresses of the Encrypted and Unencrypted Resolvers are
not the same, or the shared IP address is not a private IP address,
the client MUST NOT use the Encrypted Resolver opportunistically.
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.