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

[Tommy Pauly <[e-mail]>]

Hi Ben, 

> On Aug 4, 2022, at 2:17 PM, Ben Schwartz <bemasc=[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.

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), 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

> 
> 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.

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/
>> 
>> There is also an HTML version available at:
>> 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
>> 
>> 
>> 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
> -- 
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add