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

["STARK, BARBARA H" <[e-mail]>]

In-line with <bhs2>. Just one question, though, so no need to look far.
Barbara

From: Ben Schwartz <[e-mail]>
Sent: Sunday, October 10, 2021 9:07 PM
To: STARK, BARBARA H <[e-mail]>
Cc: ADD Mailing list <[e-mail]>
Subject: Re: Relaxed validation and delegated IPv6 prefixes (Was: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt)

 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.

<bhs2> Oh good! So by "covers", do you think it would be acceptable to have the certificate contain the IPv6 prefixes AT&T uses to delegate prefixes to wireline customers? Like 2600:1700::/28 and 2602:300::/24?

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