DHCP is automatic, so the question of what to do when you have configuration information that conflicts with DHCP needs to be addressed. It isn't "simple" simply because it addresses only one specific use case.
On Tue, Aug 21, 2018 at 12:19 PM, Vladimír Čunát <[email protected] > wrote: > Ehm, we somehow forgot that this thread is supposed to be about DHCP, so > that's only the "uninteresting" case where you do trust the ISP and want > to use their DNS over a secure channel :-D > > On 08/21/2018 05:34 PM, Philip Homburg wrote: > >> Then you have a problem that's not solvable in DNS itself (yet). That's > >> what people usually forget to consider. > >> [...] > > This is too some extent a chicken and egg problem. Without encrypted DNS > > there is no point in encrypted SNI and vice versa. > > Yes, partially. > > > I expect that encrypted SNI will be relatively easy to deploy. It can > happen > > as soon as both endpoints support it. > > > > In contrast, DNS is a very complex eco system. So it makes sense to start > > deploying encrypted DNS now, under the assumption that encrypted SNI will > > follow. > > Well, DoT has been standardized for some time, and we now have multiple > open-source implementations for client- and daemon-side, and some large > public services support it. DoH is a little later, but it might gather > more speed eventually. From *my* point of view the SNI is the biggest > hindrance ATM; other technical issues don't seem bad, at least not for > most motivated users. (Finding a trusted service might be problem for > some people, I suspect.) > > >> After SNI encryption gets widely deployed, tracking through IP addresses > >> only will be somewhat harder, so there it will start getting > >> interesting. > > We have seen already that 'domain fronting' is can be a very effective > way > > to bypass filters. For large CDNs or cloud providers, filtering based on > > IP addresses is not going to be effective. > > Centralizing most of the traffic to a few CDN providers would solve > that, but somehow I don't think privacy should depend on that. And I > don't think it's so easy to significantly reduce the information leak - > you just *move* it to somewhere else (someone else), and it's not really > clear to me in general who is more trustworthy. Still, such > possibilities certainly are nice to have. > > >> Until then, IMHO you just need to either trust the ISP or > >> tunnel *all* traffic to somewhere, e.g. via tor or VPN to some trusted > >> party. > > True. But we can take small steps to reduce unwanted interference from > ISPs. > > > > From a security point of view, it helps a lot if you can just trust DNS.. > > Instead of always having to take into account that somebody may > interfere > > with DNS replies. > > Defense against changing DNS is something else than privacy - we have > DNSSEC for that, so you don't even need to trust the server sending you > the data, but I think we're getting too much off-topic anyway... > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
