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

[Ben Schwartz <[e-mail]>]

On Fri, Aug 5, 2022 at 1:29 PM Tommy Pauly <tpauly=
[e-mail]> wrote:

>
>
> 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]> 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.
>
>
> Generally, the resolvers are going to need to get some valid certificate
> to host.
>

I don't believe that is true (in the opportunistic case that we are
discussing).


> Ideally, that covers their IP addresses for the non-private address case,
> but even in the private address case, they’ll need *some* certificate.
>

Yes, but there is no need for this certificate to chain to a trusted root
if the resolver is only known to the clients by a private IP.


> 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.”
>
>
Yes, that seems reasonable, but it does not require resolvers to provide a
certificate with a chain to a root CA recognized by the client.


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

What do you mean by "valid"?  Do you mean "chains to a CA trusted by the
client, but the SAN is not checked"?  If so, I fail to see how this check
helps the user at all.

This behavior is permitted within RFC 7858 opportunistic, but it is not
recommended.

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

As I noted earlier, if the resolver does not have a name (as most consumer
CPE does not), it is not at all clear from the current draft how to choose
the TargetName.  The same goes for any self-signed CommonName, although I
believe the choice of CommonName is entirely irrelevant, as it is ignored
by the client.

The choosing of a CommonName for a self-signed certificate is already a
very dark corner of the standards territory, but in my experience the most
common value is "localhost", which strikes me as a terrible value for a
TargetName.

> 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.
>
>
> 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 don't think the current text captures that intent.  Instead, it strongly
implies that all DDR clients are vulnerable ("can prevent" without further
qualification).  Here's a possible replacement that I think is more
neutral, accurate, and informative.

> For DDR, this attack can result in a downgrade to unencrypted DNS or a
denial of service, depending on the client's behavior.