Re: [dns-privacy] Review request: draft-btw-dprive-rfc8484-clarification

[Ben Schwartz <[e-mail]>]

On Tue, Sep 8, 2020 at 11:33 AM Neil Cook <[e-mail]> wrote:

>
>
> On 8 Sep 2020, at 15:41, Ben Schwartz <[e-mail]> wrote:
>
> Of course there are many questions that the draft makes no attempt to
> answer, including the question of how best to implement redirection.
>
>
> I’m not sure how to take the above statement. The draft explicitly tries
> to answer how to best implement redirection.
>

I was unclear; I was referring to RFC 8484.

...

> The question is: why do you need to redirect the user to a different
> origin?  There's a hint about "redirecting the client to a locally
> administered DoH server", but I wasn't able to understand the motivation.
> What is the system architecture you are trying to enable, and why?
>
>
> One of the original motivations was to enable redirection from a central
> DoH server to a DoH forwarder running on e.g. a home router (in this case
> managed and provided by the operator of the central DoH server). Thus you
> might start off talking to “https://example.com/whatever” and you would
> be redirected to “https://cpe1234.example.com/whatever”. That’s why this
> draft was in the ADD WG before dprive.
>

That's an interesting use case, and I think it deserves more exposition.
To me, it raises questions like
* How did the client get configured to use the specified URI template in
the first place?
* Why should the client use the CPE resolver instead of the central
resolver, if they are administered by the same entity?
* How does the server know which CPE to redirect the client to?
* What are the trust properties of a certificate stored on the CPE?
* Could you use IP certificates to avoid the bootstrap problem?

There are numerous potential ways to enable encryption between the client
and CPE; it's not at all obvious to me that the right solution is to
integrate with DoH in this way.

> On Tue, Sep 8, 2020 at 7:43 AM Neil Cook <neil.cook=
> [e-mail]> wrote:
>
>> Do you think that  RFC8484 provides enough information for DNS client and
>> servers to implement redirection in an interoperable way?
>
>
> Yes, insofar as it "might" work, which is all that can be said, since
> redirection itself is optional.
>
>
> It “might" work isn’t enough to develop clients and servers that
> interoperate.
>

Sure.  To be precise, RFC 8484 imposes enough requirements on clients that
a server can implement redirection in a way that works for at least some
use cases, for all RFC8484 clients that also support redirection.

...

> If so do you have any other proposals for how it could be done?
>>
>
> Servers can redirect any query except those needed to follow the redirect.
>
>
> I’m not sure if that could be easily implementable in a DNS server (the
> redirect might lead to a long chain of CNAMEs for example, and the server
> would need to maintain state across queries), but I’d be interested to see
> if it could be. If so, it would certainly be a more attractive approach.
>

You could also use static analysis to avoid keeping state across
queries, if the destination domain is cooperating (as in your example
above).  That said, this is all much simpler and more performant if the
goal is only to redirect some small category of queries, as opposed to
redirecting everything.  That goes back to the question of use cases.