Please see inline [TR]

From: dns-privacy <dns-privacy-boun...@ietf.org> On Behalf Of Neil Cook
Sent: Tuesday, March 12, 2019 5:14 PM
To: Konda, Tirumaleswar Reddy <tirumaleswarreddy_ko...@mcafee.com>
Cc: d...@ietf.org; Vittorio Bertola 
<vittorio.bertola=40open-xchange....@dmarc.ietf.org>; dnsop@ietf.org; Paul 
Vixie <p...@redbarn.org>; Christian Huitema <huit...@huitema.net>; nalini 
elkins <nalini.elk...@e-dco.com>; dns-priv...@ietf.org; Ackermann, Michael 
<mackerm...@bcbsm.com>; Stephen Farrell <stephen.farr...@cs.tcd.ie>
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 
<tirumaleswarreddy_ko...@mcafee.com<mailto:tirumaleswarreddy_ko...@mcafee.com>> 
wrote:

-----Original Message-----
From: Stephen Farrell 
<stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>>
Sent: Tuesday, March 12, 2019 5:30 AM
To: Paul Vixie <p...@redbarn.org<mailto:p...@redbarn.org>>; 
d...@ietf.org<mailto:d...@ietf.org>
Cc: nalini elkins <nalini.elk...@e-dco.com<mailto:nalini.elk...@e-dco.com>>; 
Konda, Tirumaleswar Reddy
<tirumaleswarreddy_ko...@mcafee.com<mailto:tirumaleswarreddy_ko...@mcafee.com>>;
 dnsop@ietf.org<mailto:dnsop@ietf.org>; Ackermann,
Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>>; Christian Huitema
<huit...@huitema.net<mailto:huit...@huitema.net>>; 
dns-priv...@ietf.org<mailto:dns-priv...@ietf.org>; Vittorio Bertola
<vittorio.bertola=40open-xchange....@dmarc.ietf.org<mailto:vittorio.bertola=40open-xchange....@dmarc.ietf.org>>
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
DNSOP@ietf.org<mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to