Re: [Add] Relaxed validation and delegated IPv6 prefixes (Was: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt)

[Ben Schwartz <[e-mail]>]

>
>  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.
>
>
>
> <bhs> When you say “[the DNS forwarder] could get a TLS certificate for
> that IP address”, are you saying it would be possible for a gateway to get
> a PKI CA-signed certificate every time it gets delegated an IPv6 prefix
> (and subsequent renewal)?
>

I misspoke.  Let me try again:

In DDR, the Encrypted Resolver must hold a certificate that covers the IP
address of the Unencrypted Resolver unless the resolvers have the same IP.
Thus, if the gateway uses a public IP address, and is actually a forwarder,
then the upstream resolver must return a certificate that covers the
gateway's IP address.

This is not the same as placing a PKI certificate on the gateway.  (I don't
know if it's easier or harder.)

...

> So if a client is provided a private IPv4 DNS server address and a public
> (GUA) IPv6 DNS server address (and, BTW, both reply with identical
> resolver.arpa info), will the relaxed-validation client prefer IPv6 and
> not upgrade because the IPv6 address is a GUA? Or will the
> relaxed-validation client try the private IPv4 address (also?) and do the
> DoH upgrade?
>

I think it will do the upgrade, via the IPv4 server.


> I’m ok not worrying about people with static public IPv4 address
> assignments (assuming the same argument that a certificate isn’t
> realistic). That’s a small population. But is it really not possible to
> explore allowing “same IPv4 subnet” or “on-link IPv6 prefix”?
>

Let's consider two clients, one implementing "baseline DDR" and one that
relaxes validation as you've described.  They are on a v6-only network
whose DNS server has a public IP and is "on-link" according to some
criterion.  A DDR query tells the client to use a "far away" designated
resolver.

If the local DNS server is actually a forwarder, then it is arguably safe
to upgrade without certificate validation.  However, the client doesn't
know whether this server is a forwarder.  It might actually be a full
resolver.

Suppose there is an active attacker close to the "far away" designated
resolver.  The "baseline DDR" client enforces certificate validation, so it
detects this attacker and continues to use the local (full) resolver.  As a
result, the attacker (who is far away) cannot see or modify most/any of the
user's queries.  The "relaxed" client sends all their queries straight to
the attacker.

This seems like a much larger departure from the baseline DDR security
model than anything contemplated in this draft, so I would prefer not to
combine it.  However, this situation is important, and should be mentioned
in the draft.  I've added the following paragraph in the pull request [1]:

> IPv6-only networks whose default DNS server has a Global Unicast Address
are out of scope, even if this server is actually a simple forwarder.  If
the DNS server does not use a private IP address, it is not a "legacy DNS
forwarder" under this draft's definition.

[1] https://github.com/bemasc/ddr-forwarders/pull/3