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

[Ben Schwartz <[e-mail]>]

On Fri, Sep 24, 2021 at 9:51 AM STARK, BARBARA H <[e-mail]> 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.
>

Thanks!


> I have just a few comments.
>

I've proposed changes to address some of them here:
https://github.com/bemasc/ddr-forwarders/pull/3/files?short_path=1dd9b41#diff-1dd9b41c1d07a52069cc813ecb21901ad48aa5fd4b5cccf6c664930d42e92449


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

Agreed.  The proposal changes the terminology to "private IP address",
defined as "Any IP address reserved for loopback [RFC1122], link-local
[RFC3927], private [RFC1918], local [RFC4193]), or Carrier-Grade NAT
[RFC6598] use".


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

I haven't imposed this restriction, because it doesn't seem to be
necessary.  If DHCP says the DNS server is 192.168.0.5, and the client's
address is 10.0.0.123, the logic of this draft still holds.


> or 127.0.0.0/8. This latter would be for clients that make use of stub
> resolvers.
>

Added.


> 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.
>
>
This document is focused on the case where the DNS server is only known by
a private IP address.  In this case "opportunistic security" is the best we
can do, because cryptographic identity validation is not possible.  This
draft is about exploring subtleties within the space of opportunistic
security.

If the DNS forwarder is identified by a public address (IPv4 or IPv6), then
it could get a TLS certificate for that IP address.  A client policy that
doesn't require authentication in this case, even though authentication is
possible, would be a much bigger departure from baseline DDR.  I would
prefer not to describe that behavior in this draft.

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

The DNR draft claims to override DDR.  I've added a reference to the
relevant text in the DNR draft.


> 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.
>
>
OK, I've written a stronger warning at the top of this section.

Thanks for the comments,
Ben Schwartz

>