Re: [Add] Fwd: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt

Ben,

Thanks for this draft. As Barbara says it's short and readable, and it
carefully articulates the issues.

In section 3 we could clarify "removes the certificate validation policy".
What I mean is to tighten it to clearly refer to the quoted policy in 2.1,
not  to all types of certificate validation. We still want the client to
perform normal TLS validation (e.g. correct chain of trust exists).

Section 4 is concerned with the implementation of these features *on the
legacy forwarder*. Where they are implemented on the forwarder, I agree the
way to continue to support the behaviour is to add resolver.arpa to the
blocklist. HOWEVER it would be worth also commenting on the implementation
of these same features on the upstream resolver, which I suspect is pretty
common. In this latter case, the behaviour is naturally supported as soon
as the upstream publishes the SVCB for _dns.resolver.arpa.

Caveat: this is only true if the legacy forwarder has no role in the
implementation of the features. In networks where both the forwarder and
the upstream need to co-operate (e.g. forwarder assists the upstream in
communicating the type of service required for this user), then it can only
continue if we block resolver.arpa.

Chris

On Fri, 24 Sept 2021 at 14:51, STARK, BARBARA H <bs7652@att.com> wrote:

> Hi Ben,
>
> I really like the idea presented in this draft. I think it could be very
> helpful to many end users – allowing automated upgrade to DoH for people
> behind DNS proxies who aren’t using any filtering in those DNS proxies.
>
>
>
> I have just a few comments.
>
> I think there needs to be a more complete definition of “non-public IP
> address” (or perhaps a more refined and specific set IP addresses of where
> this relaxed validation might be considered). I’m thinking it might be good
> to restrict to an IPv4 address on the same subnet, an IPv6 address in an
> on-link prefix, or 127.0.0.0/8. This latter would be for clients that
> make use of stub resolvers. Note that an IPv4 subnet and IPv6 on-link
> prefix could be comprised of globally routable addresses – so not
> necessarily “non-public” as some people might understand that word.
>
> But since we’re all trying to head for IPv6, I think it’s good to
> recognize that the IPv6 address being advertised for DNS proxies tends to
> be from the delegated prefix and not ULAs. And it might be good if we could
> support this case.
>
>
>
> I’m not too sure about the 6.1.1 mitigation solution related to
> implementing DNR. It’s not that it’s necessarily wrong -- it’s just not
> really a part of DDR-based discovery and there’s no rules around how DDR
> and DNR interact.
>
>
>
> I think the 6.1.2 and 6.1.3 mitigations should somehow be strongly
> recommended in conjunction with this technique. Though I understand the
> desire to avoid normative language, I still think it would be beneficial to
> use some lowercase recommending words.
>
>
>
> BTW, I really like how short and readable the draft is. 😊
>
> Thx,
>
> Barbara
>
>
>
>
>
> *From:* Add <add-bounces@ietf.org> *On Behalf Of *Ben Schwartz
> *Sent:* Tuesday, September 21, 2021 9:25 AM
> *To:* ADD Mailing list <add@ietf.org>
> *Subject:* [Add] Fwd: New Version Notification for
> draft-schwartz-add-ddr-forwarders-00.txt
>
>
>
> Hi ADD,
>
>
>
> I've written a new draft regarding DDR and legacy DNS forwarders ("the 85%
> problem").  This replaces my previous proposed changes to the DDR draft.
>
>
>
> Note that this draft's "intended status" is currently "Informational", on
> the theory that we are more likely to reach consensus (and stay within the
> charter) if we aren't trying to make normative rules about client policy
> details.
>
>
>
> --Ben
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Tue, Sep 21, 2021 at 10:10 AM
> Subject: New Version Notification for
> draft-schwartz-add-ddr-forwarders-00.txt
> To: Benjamin Schwartz <bemasc@google.com>
>
>
>
>
> A new version of I-D, draft-schwartz-add-ddr-forwarders-00.txt
> has been successfully submitted by Benjamin Schwartz and posted to the
> IETF repository.
>
> Name:           draft-schwartz-add-ddr-forwarders
> Revision:       00
> Title:          Discovery of Designated Resolvers in the Presence of
> Legacy Forwarders
> Document date:  2021-09-21
> Group:          Individual Submission
> Pages:          9
> URL:
> https://www.ietf.org/archive/id/draft-schwartz-add-ddr-forwarders-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-schwartz-add-ddr-forwarders/
> Html:
> https://www.ietf.org/archive/id/draft-schwartz-add-ddr-forwarders-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-schwartz-add-ddr-forwarders
>
>
> Abstract:
>    This draft describes how the Discovery of Designated Resolvers (DDR)
>    standard interacts with legacy DNS forwarders, including potential
>    incompatibilities and relevant mitigations.
>
> Discussion Venues
>
>    This note is to be removed before publishing as an RFC.
>
>    Discussion of this document takes place on the mailing list
>    (add@ietf.org), which is archived at
>    https://mailarchive.ietf.org/arch/browse/add/.
>
>    Source for this draft and an issue tracker can be found at
>    https://github.com/bemasc/ddr-forwarders.
>
>
>
>
> The IETF Secretariat
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>