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

[Ben Schwartz <[e-mail]>]

On Thu, Aug 4, 2022, 6:27 PM Tommy Pauly <tpauly=[e-mail]>
wrote:

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

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.


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

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.

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]> 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]
>> https://www.ietf.org/mailman/listinfo/add
>>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>
>
>