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

[tirumal reddy <[e-mail]>]

On Mon, 11 Oct 2021 at 07:37, Ben Schwartz <bemasc=
[e-mail]> 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)?
>>
>
> 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.
>

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


>
> 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
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>