Draft: draft-ietf-add-ddr

Commentary: Right now , we only allow authenticated and matching - IP opportunistic use of the DDR record . While use of the record in a case where authentication fails is n't safe to use automatically , we should clarify that implementations MAY choose to use the information anyhow by policy , and possibly with user control . 
 For authentication to matter , it generally has to operate without fallback . Currently the text is not very clear on this point , but it sure seems like IP - authenticated mode is expected to fall back to cleartext if no upgrade is possible . I think we need to clarify the use case for an authenticated mode , or abandon the distinction between opportunistic and authenticated . In my view , authenticated mode only makes sense if ( 1 ) the resolver is identified by its IP address AND ( 2 ) the system knows a priori that this resolver supports encrypted DNS , so that it can refuse to fall back to cleartext if the upgrade information is stripped by a network attacker . This is a sufficiently narrow use case that I lean toward dropping it entirely and recommending Discovery Using Resolver Names ( Section 5 ) or opportunistic instead . 
 Currently , this is what we say ( which I now see a grammatical error in , but there it is ): We do n't say anything else because that would be out of WG scope . The point of the document is to help a stub resolver configured with a recursive resolver known only by IP address to bootstrap into encrypted DNS . The stub resolver 's posture on whether to fall back to unencrypted DNS or simply refuse to use the resolver is its own business . Look at this through a common OS scenario : the OS stub resolver learns an IP address from DHCP , and it 's a public IP address ( my old ISP did this ) . It knows of no other resolvers because the user does n't know what DNS is and that 's the default configuration ( use network recommendation ) . If I try to use DDR and I get no answer back , then I 'm in the same position as I was before DDR : I know of no other resolver , so I either have to use this one or have no DNS resolutions . DDR did not introduce that conundrum ; it offers clients a way out of it when DNR is not present and there is no plain - text DNS attack present . The authenticated DDR mode allows such a client to be confident in the authenticity of the bootstrap even though it started over plain text . I do not agree this scenario is sufficiently narrow to drop . Is your concern over the usefulness of the scenario , or over naming it " authenticated " ? I am open to suggestions on the latter ; I strongly disagree with the former . 
 Both . How is this information useful to the client ? I have not heard of any proposal for any client to behave differently on the basis of whether its encrypted connection is authenticated , when the resolver is identified by IP address . As for the name , RFC 7435 is the reference . I find it a bit confusing , but here 's some of the relevant text : The " authenticated " section does not seem to describe an " authenticated " protocol by this definition , because it does not provide a downgrade - resistant method to determine that authentication is expected to work . 
 Please suggest a more accurate name then please . I do agree behavior naming should be consistent with other documents . Your bar for useful is apparently different from mine . Before DDR , a client configured only with an IP address had only unencrypted DNS as an option . With DDR , the client can possibly encrypt that connection . A transient attacker would have to have been present for the initial SVCB discovery to prevent that ; an attacker arriving after DDR has taken place will be kept out of the loop . In the worst case , a client is returned to square one . I do not agree that just because a mechanism can be prevented means the mechanism provides no value . It does n't have to . In the common case , the client is forced by lack of knowledge to use unencrypted DNS . If it can from that default configuration divine encrypted DNS configuration , that 's a net positive . Resolver selection is out of scope and has nothing to do with it . 
 I 've updated to address this question by reformulating the concept of authentication , and being much more explicit about the threat model . Yes , that 's a good step , but it does n't rely on authentication . This is a very helpful observation . I 've incorporated it in . 
 I believe this particular issue is largely overtaken by events . Particularly , I think we 've some clarity and escape hatches with , and protections with . 
 Same comment for line 337/360 about referring to the resolver as Designated versus Encrypted ( it 's unmodified in this PR but based on your agreement with the other in - line comment it may need modified as well ) I think we will need to add some text to the Security Considerations section to mention the security promise difference between following the MAY or not ( for optional use of the unverifiable designation ) . However , we can close this PR without it and handle that in a new PR if that 's preferable .
When a client discovers Designated Resolvers from an Unencrypted
Resolver IP address, it can choose to use these Designated Resolvers
either automatically, or based on some other policy, heuristic, or
user choice.
Authenticated Discovery authenticated, for when a TLS certificate
can be used to validate the resolver's identity.
Opportunistic Discovery opportunistic, for when a resolver is
accessed using a non-public IP address.
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 SHOULD NOT automatically use a Designated
Resolver without some sort of validation, such as the two methods
defined in this document or a future mechanism.
Authenticated Discovery is a mechanism that allows automatic use of a
Designated Resolver that supports DNS encryption that performs a TLS
handshake.
not cover the Unencrypted Resolver address, the client MUST NOT use
the discovered Encrypted 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).
If the Designated Resolver and the Unencrypted Resolver share an IP
address, clients MAY choose to opportunistically use the Encrypted
Resolver even without this certificate check (opportunistic).
If resolving the name of an Encrypted 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 Encrypted Resolver name.
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).
If the Designated Resolver and the Unencrypted 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.
While the IP address of the Unencrypted Resolver is often provisioned
over insecure mechanisms, it can also be provisioned securely, such
as via manual configuration, a VPN, or on a network with protections
like RA guard RFC6105.  An attacker might try to direct Encrypted DNS
traffic to itself by causing the client to think that a discovered
Designated Resolver uses a different IP address from the Unencrypted
Resolver.  Such an Encrypted Resolver might have a valid certificate,
but be operated by an attacker that is trying to observe or modify
user queries without the knowledge of the client or network.
If the IP address of a Designated Resolver differs from that of an
Unencrypted Resolver, clients MUST validate that the IP address of
the Unencrypted Resolver is covered by the SubjectAlternativeName of
the Encrypted Resolver's TLS certificate (authenticated).
Opportunistic use of Encrypted Resolvers MUST be limited to cases
where the Unencrypted Resolver and Designated Resolver have the same
IP address (opportunistic).
While the IP address of the Unencrypted Resolver is often provisioned
over insecure mechanisms, it can also be provisioned securely, such
as via manual configuration, a VPN, or on a network with protections
like RA guard RFC6105.  An attacker might try to direct Encrypted DNS
traffic to itself by causing the client to think that a discovered
Designated Resolver uses a different IP address from the Unencrypted
Resolver.  Such a Designated Resolver might have a valid certificate,
but be operated by an attacker that is trying to observe or modify
user queries without the knowledge of the client or network.
The constraints on validation of Designated Resolvers specified here
apply specifically to the automatic discovery mechanisms defined in
this documents, which are referred to as Authenticated Discovery and
Opportunistic Discovery.  Clients MAY use some other mechanism to
validate 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.
If the IP address of a Designated Resolver differs from that of an
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.
Clients using Opportunistic Discovery (opportunistic) MUST be limited
to cases where the Unencrypted Resolver and Designated Resolver have
the same IP address.