Please see inline [TR] From: dns-privacy <[email protected]> On Behalf Of Neil Cook Sent: Tuesday, March 12, 2019 5:14 PM To: Konda, Tirumaleswar Reddy <[email protected]> Cc: [email protected]; Vittorio Bertola <[email protected]>; [email protected]; Paul Vixie <[email protected]>; Christian Huitema <[email protected]>; nalini elkins <[email protected]>; [email protected]; Ackermann, Michael <[email protected]>; Stephen Farrell <[email protected]> Subject: Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients
CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe. ________________________________ ISTM that it is quite possible that enterprises that deploy their own DoH services could potentially reduce such leakage and gain overall. (I'm assuming here that sensible browser-makers will end up providing something that works for browsers running in networks with split-horizon setups before those browsers turn on DoH as a default at scale.) If Enterprise network provides a DoT/DoH server, browser should be able to discover and use the Enterprise DoT/DoH server. Well until now there has been no discovery mechanism for DoH servers. There is now draft adopted by the DoH WG that proposes a discovery mechanism. However whether browsers actually use it is another question. Hence the draft by VIttorio. [TR] Discovery alone will not solve the problem, the DoH client needs to trust the discovered DoH servers (see https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-01). Cheers, -Tiru Neil On 12 Mar 2019, at 06:14, Konda, Tirumaleswar Reddy <[email protected]<mailto:[email protected]>> wrote: -----Original Message----- From: Stephen Farrell <[email protected]<mailto:[email protected]>> Sent: Tuesday, March 12, 2019 5:30 AM To: Paul Vixie <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: nalini elkins <[email protected]<mailto:[email protected]>>; Konda, Tirumaleswar Reddy <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Ackermann, Michael <[email protected]<mailto:[email protected]>>; Christian Huitema <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Vittorio Bertola <[email protected]<mailto:[email protected]>> Subject: Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients (This distribution list is too scattered and diverse. Be great if some AD or someone just picked one list for this. In the meantime...) On 11/03/2019 20:43, nalini elkins wrote: impact assessment that certain changes such as DoH and TLS1.3 will have on enterprises, TLS1.3 will, I expect, noticeably improve security for an awful lot of enterprises in time. As for DoH, I wonder has anyone done studies on how split-horizon names and access patterns leak today? I don't recall having read that kind of study. I can imagine many ways in which that kind of stuff would leak. I'd be very surprised if it never happens. I don't know how often it does. For names, leaking once is kinda fatal. For access patterns, I guess one leak exposes an IP address that's interested in a name (e.g. secret- project.example.com<http://project.example.com>) but more would be needed for broader access patterns to be exposed to "foreign" recursives and/or in-band networks. ISTM that it is quite possible that enterprises that deploy their own DoH services could potentially reduce such leakage and gain overall. (I'm assuming here that sensible browser-makers will end up providing something that works for browsers running in networks with split-horizon setups before those browsers turn on DoH as a default at scale.) If Enterprise network provides a DoT/DoH server, browser should be able to discover and use the Enterprise DoT/DoH server. -Tiru Cheers, S. _______________________________________________ DNSOP mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
