On Mar 13, 2018, at 11:27 AM, Joe Abley <jab...@90.212.199.in-addr.arpa> wrote:
> The canonical service that is difficult to use (or at least bootstrap) by
> name rather than address is the DNS. If we imagine the intersection of the
> DNS and TLS to be non-zero, there's your use case. This was Paul's point.
> DNS resolvers are normally referred to by address. This does imply a need for
> address stability, and a lack of the kind of agility that is possible in
> other services. People who have renumbered popular resolvers whose failure
> has real end-user impact are nodding right now. And possibly checking their
> pockets for valium.
But I don't think you actually answered my question. I get the idea that in
theory, DNS servers are configured this way. But we are talking about a
situation where the resolver is contacting a service over TLS because, one
assumes, privacy is important, or the local network is filtering DNS, or
something like that.
So now, where is that IP address coming from? DHCP? That doesn't match the
trust model. You must be connecting to a server that you know, or else
there's no reason to prefer it to the local resolver.
If it's a server you know, you should do the trust establishment ritual when
you configure it. So the trust establishment nugget needs to contain both a
name and one or more IP addresses, not just an IP address. Problem solved, no
need for new technology, other than to specify what the trust establishment
nugget looks like.
So the interesting problem is how the server with which the host has already
established trust signals that its IP address is going to change at some time
in the future, so that the host resolver knows to switch IP addresses. It's
not how to establish trust on an IP address. If you have to establish trust
on an IP address, you've already lost.
DNSOP mailing list