Re: [Add] I-D Action: draft-ietf-add-ddr-09.txt

[Tommy Pauly <[e-mail]>]

> On Aug 4, 2022, at 7:04 PM, Ben Schwartz <bemasc=[e-mail]> wrote:
> 
> 
> 
> 
> On Thu, Aug 4, 2022, 6:27 PM Tommy Pauly <tpauly=[e-mail] <mailto:[e-mail]>> wrote:
> Hi Ben, 
> 
>> On Aug 4, 2022, at 2:17 PM, Ben Schwartz <bemasc=[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Following up on my SECDIR review:
>> 
>> Section 4
>> 
>>    Because this query is for an SUDN, which no entity can claim
>>    ownership over, the ServiceMode SVCB response MUST NOT use the "."
>>    value for the TargetName.  Instead, the domain name used for DoT/DoQ
>>    or used to construct the DoH template MUST be provided.  This ensures
>>    that different designated resolver configurations can be correctly
>>    associated with IP addresses in A and AAAA records.  As such, clients
>>    MUST NOT perform A and AAAA queries for "resolver.arpa".
>> 
>> Thanks for updating this paragraph, but I think there are still several major issues here.
>> 
>> The guidance not to use "." is weird because using "." here would be unnatural anyway.  The natural thing would be to set TargetName to "resolver.arpa".  This is also forbidden, but the text doesn't address it.
> 
> We can clarify that this shouldn’t include “resolver.arpa”.
>> 
>> The text about what to put in the TargetName is very strange.  It conflicts directly with the guidance in Section 4.2 ("The client MUST verify that the certificate contains the IP address of the designating Unencrypted DNS Resolver") and Section 6.3 ("clients MUST use the original IP address of the Unencrypted DNS Resolver as the URI host for DoH requests”).
> 
> 
> Ah, I see what you mean. That sentence ("the domain name used for DoT/DoQ") is leftover.
> 
>> 
>> Also, as I noted in my review, the justification that "no entity can claim" this name is illogical, as the resolver is already serving a response for this name.  Clearly, the resolver can indeed "claim" this name, and is already doing so.
>> 
>> Possible replacement text (along the lines suggested in my review):
>> 
>> > To enable reliable identification of the Designated Resolver for debugging and future extensions, the TargetName SHOULD NOT indicate a SUDN (either explicitly or via the special value ".").  Clients SHOULD NOT issue speculative queries for A or AAAA records associated with this SVCB RRSet.  Note that the TargetName itself does not influence the encrypted connection in any way.
> 
> Talking with my other authors, I think we don’t think that this needs to limit to only speculative queries — the client should not be performing A or AAAA queries for resolver.arpa at all, regardless of if they are speculative.
> 
> In general, forbidding a DNS client from making certain DNS queries is pretty much unheard-of.  All DNS clients are permitted by the DNS protocol to issue whatever queries they like.  If you don't want the client to issue these queries, I think it makes more sense to focus on removing the reasons why the client might want to issue the queries, rather than forbidding the queries themselves.
> 
> I also think these should remain MUST NOTs, since there is no good reason to allow them (which is the bar for a MUST NOT),
> 
> I think there are in fact good reasons to allow them.  For example, this rule is the only thing that prevents opportunistic DDR from functioning on nameless resolvers.  Consider a home network gateway that wants to implement local opportunistic DDR.  If TargetName cannot be a SUDN, then the gateway has to claim some actual domain name for the TargetName.  If the gateway doesn't have its own domain name (as the vast majority do not), it can either abandon DDR or create an (unauthenticated) split horizon, with all the complications that implies.
> 
> Alternatively, if the resolver can simply set TargetName to "resolver.arpa", it can put its own IP addresses (on the local network) in A and AAAA records on "resolver.arpa".  This has the very natural semantic of "address records on resolver.arpa are what the resolver thinks its own IPs are".
> 
> There may be some way to use .local or something to give the resolver another name, but it's not obvious to me, and seems to have much more room for error.

Generally, the resolvers are going to need to get some valid certificate to host. Ideally, that covers their IP addresses for the non-private address case, but even in the private address case, they’ll need *some* certificate. 

From the IESG review changes, we have clarified this text regarding opportunistic use:

"For this profile, Section 4.1 of [RFC7858] explains that clients might or might not validate the resolver; however, even if clients choose to perform some certificate validation checks, they will not be able to validate the names presented in the SubjectAlternativeName field of the certificate for private and local IP addresses.”

As an example, the client we run still requires having some valid certificate.

It seems reasonable that the TargetName can match whatever name the resolver chooses for its certificate name (whether that is trusted or self-signed).

>  
> but otherwise clarifying that the restriction applies to both “resolver.arpa” and “.” sounds fine.
> 
> I’ve written up this: https://github.com/ietf-wg-add/draft-ietf-add-ddr/pull/106 <https://github.com/ietf-wg-add/draft-ietf-add-ddr/pull/106>
>> 
>> Section 7:
>> 
>>    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.
>> 
>> I would prefer to make this more explicit, e.g. replacing the second sentence with
>> 
>> > To bypass attacks that affect only one server, DDR clients SHOULD first fall back to any other available Designated Resolver.  If none of the Designated Resolvers are reachable, DDR clients MAY fall back to unencrypted DNS (enabling a successful downgrade attack).  Any client that does not fall back to unencrypted DNS MUST tightly limit the SVCB TTL, which could have been chosen by an attacker (as discussed in Section 4.2).
> 
> I think this gets too far into the client policy area. We are describing the possible downgrade attack, but use of other encrypted or unencrypted resolvers and their preference order is not within the scope of this document, or group.
> 
> If you don't want to guide client policy here, then I would suggest rewording "prevent clients from switching".  As written, the text seems to imply that clients will not switch to encrypted DNS, i.e. they will continue to use unencrypted DNS.  I'd like it to be clearer that this is not the draft's intention.

The current text is trying to be merely descriptive of the risk to consider — that if an attacker blocks connections to encrypted DNS resolvers, it *can* prevent clients from switching to use encrypted DNS. It doesn’t mean it will, but it is possible depending on client behavior.

> 
> I also think that the two mitigations I described here may be helpful and non-obvious, so it seems like a shame not to remind the reader of them, normatively or not.
> 
> Note also that this is the resolution for Paul’s DISCUSS.
> 
> Thanks,
> Tommy
> 
>> 
>> On Wed, Aug 3, 2022 at 7:43 PM <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Adaptive DNS Discovery WG of the IETF.
>> 
>>         Title           : Discovery of Designated Resolvers
>>         Authors         : Tommy Pauly
>>                           Eric Kinnear
>>                           Christopher A. Wood
>>                           Patrick McManus
>>                           Tommy Jensen
>>   Filename        : draft-ietf-add-ddr-09.txt
>>   Pages           : 20
>>   Date            : 2022-08-03
>> 
>> Abstract:
>>    This document defines Discovery of Designated Resolvers (DDR), a
>>    mechanism for DNS clients to use DNS records to discover a resolver's
>>    encrypted DNS configuration.  An encrypted DNS resolver discovered in
>>    this manner is referred to as a "Designated Resolver".  This
>>    mechanism can be used to move from unencrypted DNS to encrypted DNS
>>    when only the IP address of a resolver is known.  This mechanism is
>>    designed to be limited to cases where unencrypted DNS resolvers and
>>    their designated resolvers are operated by the same entity or
>>    cooperating entities.  It can also be used to discover support for
>>    encrypted DNS protocols when the name of an encrypted DNS resolver is
>>    known.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-add-ddr/ <https://datatracker.ietf.org/doc/draft-ietf-add-ddr/>
>> 
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-add-ddr-09.html <https://www.ietf.org/archive/id/draft-ietf-add-ddr-09.html>
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-add-ddr-09 <https://www.ietf.org/rfcdiff?url2=draft-ietf-add-ddr-09>
>> 
>> 
>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>> 
>> 
>> -- 
>> Add mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>
>> -- 
>> Add mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>
> 
> -- 
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add