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

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 7 Oct 2021 20:48:40 +0000

Hi Ben,
Thanks for the draft updates. I think they're an improvement.
I just wanted to explore the topic of IPv6 delegated prefixes a little more. Comments in-line with <bhs>, with just the relevant parts of the previous email. Apologies upfront for me stream-of-consciousness expressions.
Thx,
Barbara

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.

<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)? Would this certificate need to have an expiry (valid date) consistent with the DHCPv6 IA_PD expiry (24 hours to a week)? AFAIK, the process for getting such a certificate doesn't exist (yet?). Is there some CA that offers such a thing? But, even if it did, this would require an upgrade to the gateway to somehow request and receive this certificate from the CA (with every lease renewal). I don't think we'd want a system where the CA couldn't verify that the gateway it was providing the certificate to was in possession of the IPv6 address. And this is all to support upgrade over gateways that aren't being updated. So a certificate is probably unrealistic? 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'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"?

---

From: Ben Schwartz <[email-masked]>
Date: Sun, 10 Oct 2021 22:06:50 -0400

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

---

From: tirumal reddy <[email-masked]>
Date: Mon, 11 Oct 2021 10:31:39 +0530

Using a global unicast IPv6 address for a DNS forwarder on the home router
would expose it to external attacks (e.g., DDoS, capability to resolve
private domains). If the purpose of the forwarder is to only resolve the
queries from the devices attached to the home network, I don't get why a
DNS forwarder on the home router would want to use a global unicast address
and act like a public resolver ?

Cheers,
-Tiru

On Mon, 11 Oct 2021 at 07:37, Ben Schwartz <bemasc=
[email-masked]> wrote:

> This is not the same as placing a PKI certificate on the gateway.  (I
> don't know if it's easier or harder.)
>
> ...
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 11 Oct 2021 12:39:20 +0000

The GUA address is assigned on LAN-facing interfaces only and is not reachable via the WAN interface. Just because an address is a GUA doesn't mean it has to be reachable from the Internet or via all interfaces. I suppose someone could hairpin through a compromised device on the LAN to get to it. But if they have a compromised device on the LAN, it doesn't matter what format of address is used.
Barbara

From: tirumal reddy <[email-masked]>
Sent: Monday, October 11, 2021 12:02 AM
To: Ben Schwartz <bemasc=[email-masked]>
Cc: STARK, BARBARA H <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] Relaxed validation and delegated IPv6 prefixes (Was: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt)

Using a global unicast IPv6 address for a DNS forwarder on the home router would expose it to external attacks (e.g., DDoS, capability to resolve private domains). If the purpose of the forwarder is to only resolve the queries from the devices attached to the home network, I don't get why a DNS forwarder on the home router would want to use a global unicast address and act like a public resolver ?

Cheers,
-Tiru

On Mon, 11 Oct 2021 at 07:37, Ben Schwartz <bemasc=[email-masked]<mailto:[email-masked]>> wrote:
 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)?

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'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<https://urldefense.com/v3/__https:/github.com/bemasc/ddr-forwarders/pull/3__;!!BhdT!wdNh5WKV-u2xtQFlX4hvyjwttEo6LlYpIFsOhKMSSiKdvYcs6wE6UDQCYNa2XA$>
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!BhdT!wdNh5WKV-u2xtQFlX4hvyjwttEo6LlYpIFsOhKMSSiKdvYcs6wE6UDR9Xhh1xA$>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 11 Oct 2021 13:09:28 +0000

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

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

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

...

---

From: Lanlan Pan <[email-masked]>
Date: Mon, 11 Oct 2021 22:04:33 +0800

Ben Schwartz <bemasc=[email-masked]> 于2021年10月11日周一 上午10:07写道：

> I think the "Authenticated Discovery" seems to just mean that the
Unencrypted Resolver IP address appears in certificate subject alt names,
to confirm the target Encrypted Resolver is linked to  Unencrypted Resolver.

The case gateway forwarder (with public address) to Encrypted Resolver is
not " Authenticated Discovery", but it can work.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 13 Oct 2021 11:26:48 -0400

On Mon, Oct 11, 2021 at 9:09 AM STARK, BARBARA H <[email-masked]> wrote:

>
>
> *From:* Ben Schwartz <[email-masked]>
>
> <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?
>

In principle, yes.  X.509 doesn't seem to support IP ranges (or IP
wildcards) in subjectAltName, but I think someone could write a draft to
enable that.

---

From: tirumal reddy <[email-masked]>
Date: Thu, 14 Oct 2021 15:59:15 +0530

> wildcards) in subjectAltName, but I think someone could write a draft to

It is already covered https://datatracker.ietf.org/doc/html/rfc8738. ACME
IP identifier validation extension discusses how to get a certificate with
a public IP address. I hope CA like letsencrypt will soon support this
extension.

Cheers,
-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Thu, 14 Oct 2021 16:43:14 +0530

> then the upstream resolver must return a certificate that covers the

The challenge is the certificate of upstream resolver will have to cover
the IP addresses of several legacy gateways. I meant the unupgradable
gateway could be tens of thousands and it is not feasible to cover all the
legacy gateway IP addresses in the certificate.

-Tiru

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 14 Oct 2021 14:59:05 +0000

>> In principle, yes.  X.509 doesn't seem to support IP ranges (or IP wildcards) in subjectAltName, but I think someone could write a draft to enable that.

> It is already covered rfc8738. ACME IP identifier validation extension discusses how to get a certificate with a public IP address. I hope CA like letsencrypt will soon support this extension.

Making sure I understand this...  Am I correct in reading  that RFC8738 is for specific IP addresses and not prefixes, and it's about devices using certificates they present to assert their (IP address) identity? The DDS certs being discussed aren't presented by the DNS forwarder, and an ISP (like my employer) needs to be able to have a single certificate that would work for applications behind millions of DNS forwarders. 
Barbara

---

From: tirumal reddy <[email-masked]>
Date: Mon, 18 Oct 2021 12:57:52 +0530

On Thu, 14 Oct 2021 at 20:29, STARK, BARBARA H <[email-masked]> wrote:

> >>>> 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
> > It is already covered rfc8738. ACME IP identifier validation extension
> discusses how to get a certificate with a public IP address. I hope CA like
> letsencrypt will soon support this extension.
>
> Making sure I understand this...  Am I correct in reading  that RFC8738 is
> for specific IP addresses and not prefixes, and it's about devices using
> certificates they present to assert their (IP address) identity?

Yes.

> The DDS certs being discussed aren't presented by the DNS forwarder, and
> an ISP (like my employer) needs to be able to have a single certificate
> that would work for applications behind millions of DNS forwarders.

Got it, RPKI can potentially solve the problem (see
https://rpki.readthedocs.io/en/latest/rpki/introduction.html).

-Tiru