On Thu 2015-04-09 10:36:17 -0400, Phillip Hallam-Baker wrote:
> As I see it, there are two sub-problems:
>
> 1) How does a client discover and establish a binding to a DPRIV service?
> 2) What transport/sessions(s) are supported for queries?
>
> Before answering either, I think it is pretty clear that at some point
> in the future, SPUD will be the logical choice for transport/session.
> It is also clear that we should not build research on research.
>
> So the way forward as I see it should be that our answer to (1) should
> support some mechanism for advertising alternative transports so we
> can use TLS for now and make use of SPUD if and when it matures.
I'm not convinced that SPUD is the long-term way forward, fwiw. But
there was enough discord between the different proposals within DPRIVE
that "use TLS for now" seems like it would be a great consensus to come
to. I hope we reach it.
I'd like to make sure we have a clear sense of how to do this securely
and efficiently independently of wrangling about this next part:
> The hard part of the problem is all in problem 1. I designed,
> implemented and wrote the draft for the transport/session part in a
> day. It isn't a difficult problem (if you are only solving DNS, SPUD
> is a lot harder). The hard question is how to discover and establish a
> binding to the DNS service before you have DNS.
I don't think this is quite as hard as you're making it out to be.
We're going from:
* for each resolver, get:
- an IP address
to:
* for each resolver, get:
- an IP address
- a privacy-preserving transport mechanism
- a trust anchor
Current discovery mechanisms are:
* Manual configuration
* DHCP
i think most people consider DHCP configuration to be at best minimally
useful for DPRIVE -- it leaves you vulnerable at network connection
time, but then protects you against subsequent attacks. *shrug*
Perhaps DHCP could be seen as a mechanism to propose available choices
for manual configuration?
At any rate, i think we shouldn't block transport mechanism work on
discovery mechanism work.
--dkg
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
