On 8/19/18, 1:02 PM, "DNSOP on behalf of Doug Barton" <dnsop-boun...@ietf.org
on behalf of do...@dougbarton.us> wrote:
> Personally I see securing the path from the stub to the resolver as a
good step in the ultimate goal of encrypting all of the things. :)
[JL] No disagreement here. I think the issue may be more to do with choice over
the resolver (how it gets assigned). To date on the Internet that's all been
down to local policy or user choice to override those policies, but now it
seems like the alternative proposal may look like a centralized / top-down
policy model. That's probably more the friction point than the encryption
itself.
> So the question isn't, "Why encrypt?" the question is, why on earth
wouldn't you want to?
[JL] Again, I agree. I think it boils down quite simply to how the resolver is
assigned, and whether user choice or local policy can override that assignment,
and perhaps as well what data is passed from recursive to authority (e.g.
EDNS-CS).
> So it's unlikely that an ISP would deploy DOH or DOT
in the first place,
[JL] I would not make that assumption; it could well be ISPs would be natural
early adopters given the chance to do so.
> so the idea of a DHCP option to support it isn't
necessarily relevant in that environment. That doesn't mean it's not
relevant elsewhere.
[JL] It seems silly not to allow for a way for DHCP assignment of DOH/DOT
servers. Surely it must be the case this is possible? If the network wants to
assign them, then so be it IMO. The user can always ignore and override that
optionally - as they do today with various public recursive resolvers.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
