Subject: Re: [Add] Soliciting input on "DDR and Forwarders"

From: tirumal reddy <[email-masked]>
Date: Tue, 8 Mar 2022 13:14:13 +0530

Hi Ben,

Agree with the legacy DNS forwarder problem and the proposed solution:

Comments below:

1. Any network device will have vulnerabilities (including cloud workloads)
and needs to be updated periodically to fixed versions. The home routers
that cannot be upgraded are most likely already compromised because of
existing vulnerabilities. It will be helpful to articulate this threat and
assume the attacker will always be on-path residing on the legacy
unpatchable home router.

2. I like using the reputation of the resolver without burdening an average
user. A public database or consensus algorithm among OS and browsers would
increase the number of trusted resolvers. It would also reduce the burden
of an ISP to reach each and every OS and browser vendor (to be added to the
TRR).

3.
https://datatracker.ietf.org/doc/html/draft-schwartz-add-ddr-forwarders-01#section-7.4,
it may not work with headless IoT devices.

4. A timeline (e.g., 5 or 10 years) to sunset the proposed mechanism would
be helpful.

5. If the discovered resolver is not trusted, a warning to the user will be
helpful (e.g., to upgrade the router).

6. I don't get the relevance of sections 4.1, 4.2 and 4.3 to this
specification.

7.
https://datatracker.ietf.org/doc/html/draft-schwartz-add-ddr-forwarders-01#section-7.1

a) what kind of split-horizon namespaces are you referring to in home
networks ?
b) I don't think this type of network will support homenet (see
https://datatracker.ietf.org/doc/html/rfc8375) ?

Best Regards,
-Tiru

On Wed, 23 Feb 2022 at 22:49, Ben Schwartz <bemasc=
[email-masked]> wrote:

> Hi ADD,
>
> At IETF 112, we presented [1] an Informational draft [2] describing how
> encrypted DNS upgrade procedures are likely to interact with legacy DNS
> forwarders (the "85% problem"), including problems that are likely to arise
> and some relevant mitigations.  (See most recent thread on the mailing list
> [3].)
>
> I would like to see if the group has any more input on this draft,
> especially if there are changes you would like to see before a Call for
> Adoption.
>
> Thanks,
> Ben Schwartz
>
> [1]
> https://datatracker.ietf.org/meeting/112/materials/slides-112-add-ddr-and-legacy-forwarders-00.pdf
> [2]
> https://datatracker.ietf.org/doc/html/draft-schwartz-add-ddr-forwarders-01
> [3] https://mailarchive.ietf.org/arch/msg/add/OUryQAjz_NivMNdGPkdoSldBBJo/
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 8 Mar 2022 17:36:39 -0500

Thanks for the comments, Tiru.  I've posted a PR to address some of them
here: https://github.com/bemasc/ddr-forwarders/pull/4

On Tue, Mar 8, 2022 at 2:44 AM tirumal reddy <[email-masked]> wrote:

> 1. Any network device will have vulnerabilities (including cloud
> workloads) and needs to be updated periodically to fixed versions. The home
> routers that cannot be upgraded are most likely already compromised because
> of existing vulnerabilities. It will be helpful to articulate this threat
> and assume the attacker will always be on-path residing on the legacy
> unpatchable home router.
>

This is a good point, but nothing here assumes that the router is
"unpatchable".  The problem is that implementing DDR on a pre-existing
gateway device is far from trivial.  It requires running an encrypted DNS
(IMHO likely DoH) server, which may be difficult or impossible on legacy
hardware.

> of an ISP to reach each and every OS and browser vendor (to be added to the

I have no objection to that, but I don't think it's something that can
happen inside the IETF.

3.
> it may not work with headless IoT devices.

I don't see a problem.  IoT devices still need to be administered by
somebody through some controls, even if those controls are over the network.

> be helpful.

I added a note related to this in the PR.  I don't think a fixed timeline
is appropriate, but it's a good reminder that we don't expect this to be
relevant forever.

> helpful (e.g., to upgrade the router).

Added.

> specification.

This is an Informational document, providing an overview of the topic,
including problems and various mitigations.  Section 4 discusses some less
problematic aspects of this situation.

7.
> a) what kind of split-horizon namespaces are you referring to in home

This document is not limited to home networks.  Even if this problem is
only present in home networks, devices don't know whether a given network
is a "home network", so we need to consider the impact on enterprise
networks as well.

I do think there are some home networks with split DNS, but probably not
too many.

> https://datatracker.ietf.org/doc/html/rfc8375) ?

I'm not sure I understand.  NXDOMAIN fallback would seem to enable support
for .home.arpa and https://datatracker.ietf.org/doc/html/rfc8375#section-6.3
discusses possible client behavior changes as well.

---

From: tirumal reddy <[email-masked]>
Date: Wed, 9 Mar 2022 14:20:22 +0530

Hi Ben,

Please see inline

> (IMHO likely DoH) server, which may be difficult or impossible on legacy

Home networks will have both legacy routers and routers with network
security services. For instance, several security companies offer home
network network security on home routers (e.g.,
https://www.mcafee.com/consumer/en-au/store/SHP.html,
https://www.trendmicro.com/en_us/forHome/products/homenetworksecurity.html
etc.).
In my previous company, Secure Home Platform (SHP) is shipped on millions
of home routers with hardened OpenWRT. We are able provision a DoH/DoT
forwarder and each router was provisioned with a unique domain name (e.g.,
cpe1.example.com) and was assigned a PKIX certificate using ACME (see
https://datatracker.ietf.org/doc/html/draft-boucadair-add-deployment-considerations-00#section-4.1
for more details).

The legacy routers fall into three categories (1) cannot upgrade to support
encrypted DNS forwarder but patchable (2) cannot upgrade to support encrypted
DNS forwarder, not patchable and configuration cannot be modified (3) cannot
upgrade to support encrypted DNS forwarder but configuration is updated to
use the ISP DNS resolver (both encrypted and unencrypted).

My understanding is the proposed mechanism in your draft can be used for
both (1) and (2) deployments.

>
> 2. I like using the reputation of the resolver without burdening an
>> average user. A public database or consensus algorithm among OS and
>> browsers would increase the number of trusted resolvers. It would also
>> reduce the burden of an ISP to reach each and every OS and browser vendor
>> (to be added to the TRR).
>>
>

It could be an experimental draft just like certificate transparency.

> somebody through some controls, even if those controls are over the network.

IoT devices can be on-boarded both automatically and with user assistance
(see
https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-secure-bootstrapping).
However, I agree the latter mode is popular today.

> is appropriate, but it's a good reminder that we don't expect this to be

Works for me.

>
> 5. If the discovered resolver is not trusted, a warning to the user will
>> be helpful (e.g., to upgrade the router).
>>
>
> Added.
>

Thanks.

> problematic aspects of this situation.

The draft is relaxing the mandatory validation discussed in DDR and is an
update to DDR. I am not sure about the Informational status of the draft !

> is a "home network", so we need to consider the impact on enterprise

I thought the problem was specific to home networks.

> I do think there are some home networks with split DNS, but probably not

I doubt if any home network would have split DNS with legacy forwarders.

> for .home.arpa and
> https://datatracker.ietf.org/doc/html/rfc8375#section-6.3 discusses
> possible client behavior changes as well.
>

Yes, but my comment was if these legacy forwarders would even understand
DNS queries with ".home.arpa" and not forward it.

-Tiru

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 9 Mar 2022 11:45:44 -0500

On Wed, Mar 9, 2022 at 3:50 AM tirumal reddy <[email-masked]> wrote:
...

> The legacy routers fall into three categories (1) cannot upgrade to
> support encrypted DNS forwarder but patchable (2) cannot upgrade to
> support encrypted DNS forwarder, not patchable and configuration cannot
> be modified (3) cannot upgrade to support encrypted DNS forwarder but
> configuration is updated to use the ISP DNS resolver (both encrypted and
> unencrypted).
>

I agree.

...

> update to DDR. I am not sure about the Informational status of the draft !

The DDR draft has already been adjusted to avoid this problem.  It now
contains this paragraph:

> A client MAY additionally use a discovered Designated Resolver ... 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.

This draft can be viewed as discussing, but not recommending, some other
possible resolver selection policies.

---

From: tirumal reddy <[email-masked]>
Date: Thu, 10 Mar 2022 12:19:46 +0530

>> both (1) and (2) deployments.

You may want to discuss the threats associated with (1) in the draft.

> possible resolver selection policies.

Got it, Thanks. I am not convinced about "user input", how will a user
identify the encrypted resolver is hosted by the ISP or by an attacker
(e.g., homoglyph phishing attack) ?
-Tiru