Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Konda, Tirumaleswar Reddy]

Please see inline

From: Eric Rescorla 
Sent: Tuesday, March 12, 2019 9:28 PM
To: Konda, Tirumaleswar Reddy 
Cc: d...@ietf.org; dn...@ietf.org; dns-privacy@ietf.org; Vittorio Bertola 
; Stephen Farrell 

Subject: Re: [Doh] [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.





On Tue, Mar 12, 2019 at 8:51 AM Konda, Tirumaleswar Reddy 
mailto:tirumaleswarreddy_ko...@mcafee.com>> 
wrote:
Hi Eric,

In TLS 1.2, it is possible for firewalls to inspect the TLS handshake, and 
white-list, black-list and grey-list TLS session based on the server identity. 
In other words, middleboxes are conditionally acting as TLS proxies to specific 
servers (categorized in the grey-list).
With TLS 1.3 and encrypted SNI, the middle box now has to act as a TLS proxy 
for all the flows.

It would be most useful not to conflate TLS 1.3 and ESNI.

In ordinary TLS 1.3, the SNI is in the clear but the server cert is not. 
However, importantly, even in TLS 1.2, the server certificate is not 
verifiable, and therefore is not significantly more trustworthy than SNI.

[TR] Middle boxes have a trust store (e.g. downloaded from Mozilla CA store) to 
validate the server certificate.  Malwares lie about SNI (typically use a FQDN 
whose reputation score is good), validating the server certificate (e.g. 
certain types of malwares  use self-signed certificates) and SNI mismatch helps 
detect the client is lying.

With ESNI, the SNI is encrypted (hence the name). However, the xpectation is 
that enterprises which want to do conditional inspection will disable ESNI on 
the client. This should not be problematic as they already need access to the 
client to install their own trust anchor.

[TR] I see Firefox has given an option to disable ESNI, hopefully others will 
provide a configurable option.

Cheers,
-Tiru

-Ekr



-Tiru

From: Eric Rescorla mailto:e...@rtfm.com>>
Sent: Tuesday, March 12, 2019 3:14 AM
To: Paul Vixie mailto:p...@redbarn.org>>
Cc: nalini elkins mailto:nalini.elk...@e-dco.com>>; 
Konda, Tirumaleswar Reddy 
mailto:tirumaleswarreddy_ko...@mcafee.com>>;
 d...@ietf.org; dn...@ietf.org; 
Ackermann, Michael mailto:mackerm...@bcbsm.com>>; 
Christian Huitema mailto:huit...@huitema.net>>; 
dns-privacy@ietf.org; Vittorio Bertola 
mailto:40open-xchange@dmarc.ietf.org>>;
 Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>>
Subject: Re: [Doh] [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.





On Mon, Mar 11, 2019 at 11:13 AM Paul Vixie 
mailto:p...@redbarn.org>> wrote:


nalini elkins wrote on 2019-03-11 10:26:
> Tiru,
>
> Thanks for your comments.
>
>  > Enterprise networks are already able to block DoH services,
i wonder if everyone here knows that TLS 1.3 and encrypted headers is
going to push a SOCKS agenda onto enterprises that had not previously
needed one,

I'm pretty familiar with TLS 1.3, but I don't know what this means. TLS 1.3
doesn't generally encrypt headers any more than TLS 1.2 did, except for
the content type byte, which isn't that useful for inspection anyway.
Are you perchance referring to encrypted SNI? Something else?

-Ekr

and that simply blocking every external endpoint known or
tested to support DoH will be the cheaper alternative, even if that
makes millions of other endpoints at google, cloudflare, cisco, and ibm
unreachable as a side effect?

CF has so far only supported DoH on 1.1.1.0/24 and 
1.0.1.0/24, which i
blocked already (before DoH) so that's not a problem. but if google
decides to support DoH on the same IP addresses and port numbers that
are used for some API or web service i depend on, that web service is
going to be either blocked, or forced to go through SOCKS. this will add
considerable cost to my network policy. (by design.)

--
P Vixie

___
Doh mailing list
d...@ietf.org
https://www.ietf.org/mailman/listinfo/doh
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Eliot Lear]

Gentlemen,

This conversation has gone to the zoo.  What is or is not political doesn’t 
matter at this stage in the game, and neither is arguing over rights over bits. 
 If people want to do that I suggest doing so in the HRPC WG and with a draft 
in hand.  Flaming back and forth without an objective of actually modifying 
text or developing a work proposal is quite pointless.

What is important is to document the technical ramifications of the changes 
brought about by DoH.  To move things forward, can we simply go through the 
drafts in the side meeting, and indicate what administrators might do about any 
perceived negative effects?  Whether those effects seem negative to you only 
matters if there is a proposal for the IETF to take on new work to “correct” 
them.

Eliot

> On 13 Mar 2019, at 03:59, Christian Huitema  wrote:
> 
> 
> 
> On 3/12/2019 2:11 PM, Paul Vixie wrote:
>>> I don't see why, based on your argument, your concerns
>>> trump his.
>>> 
>>> Can you explain?
>> he's trying to achieve a political aim using technology. that is not the
>> purpose for which the internet engineering task force, or the internet 
>> itself,
>> was convened. it is not why our employers pay our travel costs. and it is not
>> why the rest of the world trusts our outputs.
> 
> Sorry, but no. I am vying for network transparency, and I believe that if 
> filtering is to be enforced, it should be controlled by the user. You are 
> claiming that safety mandates giving the network operator full control over 
> name resolution. Both of these positions come from specific visions about how 
> the network should work. Neither is more a political goal than the other.
> 
> -- Christian Huitema
> 
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Christian Huitema]

On 3/12/2019 9:25 PM, Vittorio Bertola wrote:
>> Il 13 marzo 2019 alle 4.39 Christian Huitema  ha 
>> scritto:
>>
>> On 3/12/2019 7:56 PM, Vittorio Bertola wrote:
>>> The reaction I got from some policy people when I mentioned this kind of 
>>> arguments going on here is "when did the IETF get the mandate to decide for 
>>> everyone that content filtering by intermediaries is always bad? This is 
>>> matter for competition / telco / human rights legislation, and will vary 
>>> country by country."
>> The mirror image of that statement is, "when did intermediaries get a
>> mandate to filter content?"
> When a regularly elected government, having sovereignty over them and their 
> users, told them that they can / should / must do it.
>
> Note that I don't particularly like this practice (I'm currently busy in the 
> battle against Article 13 in the EU), I'm just trying to sort out everyone's 
> role in this discussion. 

The legal mandate is really a best effort mandate, as in "if you provide
name resolution, you should not resolve name X, Y and Z". It is a
constraint on the way a service provider provides a specific service. It
is not a grant of monopoly, that only the connectivity provider should
provide name resolution. It could perhaps be interpreted to say that DoH
providers, subject to the same laws as ISP, should perform the same
filtering. But that's a different question.

-- Christian Huitema

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Concerns around deployment of DNS over HTTPS (DoH)

[Kenji Baheux]

On Wed, Mar 13, 2019, 12:49 Paul Wouters  wrote:

> On Wed, 13 Mar 2019, Kenji Baheux wrote:
>
> > I'm involved with Chrome's DoH efforts.
>
> > Our motivations in pursuing DoH in Chrome is to offer our users a better
> user experience:
>
> > Hopefully, some performance wins.
>
> > Tentative plans:
>
> > We are considering a first milestone where Chrome would do an
> automatic upgrade to DoH when a user’s existing resolver is capable of it.
>
> I'm confused how these two can both be done? You either prefer the local
> ISP over Google DNS, or you prefer the faster of the two.
>

We would not change the underlying DNS provider. The only thing that would
change is how the DNS query is done: vanilla or DoH (if the existing DNS
provider is capable of it).

Discovery is an open question.

Until there is a better discovery story, we could have a list of
known-to-be-DoH-compatible DNS providers that we could check against and
map accordingly. Obviously, this doesn't scale but it seems reasonable for
the experimentation phase (gathering data, etc).






> > There are some unanswered questions about how we will be doing that
> discovery, and would welcome input from the community. Perhaps, a good
> topic for IETF 104.
>
> that is interesting indeed. You doing some static name lookups to test
> would just make those names be in cache and not a good probe. And
> probing nonsense is something that you do too much of already and it
> is causing too much root zone noise :P
>

(^ ^;


> > PS: I won't be able to join IETF 104 to discuss this face to face
>
> I'm already envious :)
>
> Paul
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Vittorio Bertola]

> Il 13 marzo 2019 alle 4.39 Christian Huitema  ha scritto:
> 
> On 3/12/2019 7:56 PM, Vittorio Bertola wrote:
> > The reaction I got from some policy people when I mentioned this kind of 
> > arguments going on here is "when did the IETF get the mandate to decide for 
> > everyone that content filtering by intermediaries is always bad? This is 
> > matter for competition / telco / human rights legislation, and will vary 
> > country by country."
> 
> The mirror image of that statement is, "when did intermediaries get a
> mandate to filter content?"

When a regularly elected government, having sovereignty over them and their 
users, told them that they can / should / must do it.

Note that I don't particularly like this practice (I'm currently busy in the 
battle against Article 13 in the EU), I'm just trying to sort out everyone's 
role in this discussion. 

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Christian Huitema]

On 3/12/2019 7:56 PM, Vittorio Bertola wrote:
> The reaction I got from some policy people when I mentioned this kind of 
> arguments going on here is "when did the IETF get the mandate to decide for 
> everyone that content filtering by intermediaries is always bad? This is 
> matter for competition / telco / human rights legislation, and will vary 
> country by country."


The mirror image of that statement is, "when did intermediaries get a
mandate to filter content?" The internet architecture assumes full
connectivity. At some point, people deployed middle-boxes and filtered
content because they could. They did not exactly try to get a mandate,
or obtain consensus that this was proper. Technologies like DoH force
the discussion in the open. Why do you think you can filter content? Who
made you king?

-- Christian Huitema

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Concerns around deployment of DNS over HTTPS (DoH)

[Paul Wouters]

On Wed, 13 Mar 2019, Kenji Baheux wrote:


I'm involved with Chrome's DoH efforts.



Our motivations in pursuing DoH in Chrome is to offer our users a better user 
experience:



Hopefully, some performance wins.



Tentative plans:



We are considering a first milestone where Chrome would do an automatic 
upgrade to DoH when a user’s existing resolver is capable of it.


I'm confused how these two can both be done? You either prefer the local
ISP over Google DNS, or you prefer the faster of the two.


There are some unanswered questions about how we will be doing that 
discovery, and would welcome input from the community. Perhaps, a good topic 
for IETF 104.


that is interesting indeed. You doing some static name lookups to test
would just make those names be in cache and not a good probe. And
probing nonsense is something that you do too much of already and it
is causing too much root zone noise :P


PS: I won't be able to join IETF 104 to discuss this face to face


I'm already envious :)

Paul

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Raymond Burkholder]

On 2019-03-12 2:51 p.m., Paul Vixie wrote:

...  development of protocols whose ideal state is "interoperability"
and never more or less.


slightly out of context, but I find the 'interoperability' context as an 
underlying definition worthy of support.


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Christian Huitema]

On 3/12/2019 2:11 PM, Paul Vixie wrote:
>> I don't see why, based on your argument, your concerns
>> trump his.
>>
>> Can you explain?
> he's trying to achieve a political aim using technology. that is not the 
> purpose for which the internet engineering task force, or the internet 
> itself, 
> was convened. it is not why our employers pay our travel costs. and it is not 
> why the rest of the world trusts our outputs.

Sorry, but no. I am vying for network transparency, and I believe that
if filtering is to be enforced, it should be controlled by the user. You
are claiming that safety mandates giving the network operator full
control over name resolution. Both of these positions come from specific
visions about how the network should work. Neither is more a political
goal than the other.

-- Christian Huitema

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[nalini elkins]

Paul,

On Wed, Mar 13, 2019 at 1:03 AM Paul Vixie  wrote:

> On Tuesday, 12 March 2019 15:36:36 UTC Stephane Bortzmeyer wrote:
> > On Mon, Mar 11, 2019 at 08:55:18AM +0530,
> >  nalini elkins  wrote
> >
> >  a message of 202 lines which said:
> > > The questions that the Fortune 50 company architect asked were
> something
> > > like this:
> > >
> > > 1. You mean that DNS could be resolved outside my enterprise?
> >
> > I suggest to explain to this person that it was possible before, as
> > any malware author discovered.
>
> no, it was not possible before. or rather, it could be cheaply prevented
> before.
>
> > If people responsible for networks of Fortune 50 company don't know
> > that it is difficult to stop unwanted communication (except when you
> > control all the endpoints, or when you airgap your network), then it
> > is indeed a problem :-)
>
> in my own travels, i've met some fortune-level CISO's who had not yet been
> told that RDNS monitor/control bypass was now an internet standard, and
> that
> behavioural modeling based on TCP/443 endpoints was no longer practical.
> so, i
> urge greater efforts on getting the word out.
>
> vixie
>
>
>
Thank you.

-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Vittorio Bertola]

> Il 13 marzo 2019 alle 3.20 Raymond Burkholder  ha 
> scritto:
> 
> It appears to me that there is considerable support for DoH, meaning 
> there is support for non-interference.

I think there is support within the IETF, but "non-interference" on DNS has 
lots of implications at the legal, business, policy and political levels, which 
implies that there are many more stakeholders than the technical community, and 
these stakeholders have never been asked what they think of this. This is part 
of the discussion that needs to happen to get to broad consensus on DoH 
deployment models, as opposed to a technical arms race to enable/stop DoH 
between the Web people on one side and the security, ISP and government people 
on the other.

> How would the requirements of each group be recognized?  The simplest 
> would be to not proceed with DoH.

My draft attempts exactly to promote a discussion to find the conditions (if 
any exist) under which DoH could be deployed  broadly without making any 
stakeholder group [too] unhappy.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Raymond Burkholder]

On 2019-03-12 4:51 p.m., Paul Vixie wrote:

On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote:
DoH intends "to prevent on-path interference with DNS operations", and that's
well beyond the remit of RFC 7626, and is therefore not spoken to one way or
another by IETF consensus. i do not believe that a non-interference objective
would reach broader IETF consensus. perhaps we can test that one day.


I'm not sure I understand the double-double negative happening here.

It appears to me that there is considerable support for DoH, meaning 
there is support for non-interference.


In the IPv6 spectrum with the mac/slaac randomization games which have 
become standardized, and which have been instituted to supply other 
forms of security/hiding/non-interference, it appears that DoH would 
similarly be 'allowed' through the standardization process.


Having said that, and if this is how one performs the testing, I would 
have to say that DoH would be make it much harder for me as a security 
engineer to perform my duties.


It would seem that if DoH is standardized, then it would probably become 
standard practice, then like 8.8.8.8 and similar quads, by default 
meaningful data becomes hidden for managing the interior of networks.


For some networks, pi-hole is a mechanism for preventing certain traffic 
operations.  AS I look at it this moment, it has over 112K domains 
blacklisted, and on one particular network, 31% of the queries have been 
blocked as a passive protection mechanism.


I find these blocks useful.  With DoH, probably DoH would become 
ubiquitous, and these types of blocks would be prevented.


Https is common ground for much hiding.  DNS is probably our last 
bastion of having any semblance of identification of what is happneing 
to the interior of our networks.  Carriers might not be so concerned. 
But for those who operation enterprise, business, home, some forms of 
social protection, security management becomes more difficult.


As has happened in the IPv6 space, the same happens here in the DNS 
space: there are groups who wish the privacy/non-interference/hiding 
ability vs the groups who need the information in the data streams to 
properly secure and manage the interior and perimeter.


How would the requirements of each group be recognized?  The simplest 
would be to not proceed with DoH.


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Stephen Farrell]

Hiya,

On 13/03/2019 01:04, Paul Wouters wrote:
> RPZ allows filtering answers which would turn into BOGUS for
> DNSSEC validating clients.

Could well be my terminology was imprecise. What I recalled
from some discussion a year or more ago was that RPZ MUST NOT
change a DNSSEC-signed answer that verifies.

If that's wrong or no longer the case then my point there is
off base. (I'll go back and find another tomorrow:-)

If I'm correct, then I remain puzzled as to why Paul V. finds
it acceptable to be unable to "interfere" with DNS answers in
one case (RPZ-with-good-DNSSEC) but not the other (DoH).

Cheers,
S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Paul Wouters]

On Tue, 12 Mar 2019, Paul Vixie wrote:


i don't like the chinese government's rules for the great firewall. so, i keep
my visits to that otherwise-great country short. this hurts me, and maybe
hurts them also. but, it's their country, and i will obey their laws when i am
using their network. and then i'll vote with my feet, to get to a better
network with better rules.


This is spoken from priviledge and really pretty unfair to claim.

If tomorrow Trump installed mandated ISP DNS firewalls with RPZ that
every MUST use and is a crime to not use, and fbi.gov is filtered like
tiananmen square you would not follow your governments rules because it
is their/your country, nor denaturalize yourself and move country.

I remember all the people who would leave California if Arnold would
become governor. Or when Bush would be elected. Twice. And those who
would leave when Trump would be elected. I know of exactly 0 individuals
who kept their promise.

Paul

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Paul Wouters]

On Wed, 13 Mar 2019, Stephen Farrell wrote:


Hmm. Not sure what to make of that. DNSSEC presumably makes it
possible to detect interference, and yet RPZ (IIRC) calls for
not changing DNSSEC-signed answers. I don't get why an inability
to change is ok for the RPZ/DNSSEC context but not for DoH.


no. RPZ allows filtering answers which would turn into BOGUS for
DNSSEC validating clients. I am waiting for RPZ to be an RFC to
start a bis document that moves the Answer to the Authoritative
section, so you can indeed detect the network's desire for protecting
you, and use DNSSEC to confirm you are not censored without consent.

Paul
ps. I owe the ISE a rpz document review, so it is partially my fault
this is stuck now. I hope to get enough airplane time in the next two
weeks to fix that :)

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

[Mark Andrews]

> On 13 Mar 2019, at 3:02 am, Jim Reid  wrote:
> 
> 
> 
>> On 12 Mar 2019, at 15:49, Stephane Bortzmeyer  wrote:
>> 
>> the case of a commercial
>> Internet access provider is clear in the other direction: a client is
>> not an employee, and is entitled to a free, open and neutral Internet
>> access.
> 
> Stephane, that’s simply not true. A client of an Internet access provider is 
> entitled to the service that they contractually agreed to pay for. Check the 
> small print. Or the T the next time you use some coffeeshop’s wifi. Even 
> if your ISP offers you “free, open and neutral Internet access” (for some 
> definition of that phrase), I’m pretty sure they’ll drop your service if you 
> were damaging their network or or doing something else that was illegal or 
> otherwise in breach of their T

And what part of doing a DNS lookups breaks any reasonable terms and conditions?

> ___
> DNSOP mailing list
> dn...@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Stephen Farrell]

Hiya,

On 12/03/2019 22:51, Paul Vixie wrote:
> On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote:
>> On 12/03/2019 21:11, Paul Vixie wrote:
>>> ...
>>
>> There are reasons to want confidentiality for DNS queries
>> and answers, and access patterns, for which the IETF has
>> achieved consensus. (See RFC7626) (*)
> 
> i have no qualms about confidentiality, for traffic allowed by a network 
> operator. 

To me, the above reads as self-contradictory. If the traffic is
confidential the operator doesn't know if its "allowed" except
possibly in some extremely coarse-grained sense. Perhaps when
you said "traffic allowed" maybe you meant "protocol allowed"?
But even that is confusing, given the likes of websockets, alpn,
and other webby ways in which stuff gets layered on 443 all
the time.

> it's the inability to interefere (as called for in RFC 8484) and not 
> the inability to observe (as called for in RFC 7626) that's at issue here.

Hmm. Not sure what to make of that. DNSSEC presumably makes it
possible to detect interference, and yet RPZ (IIRC) calls for
not changing DNSSEC-signed answers. I don't get why an inability
to change is ok for the RPZ/DNSSEC context but not for DoH.

Another possibility is that we're discovering that when this
confidentiality stuff gets used for real, we find that we'd
really prefer to not have to change what we've been doing before.
I don't mean that as an accusation but it has been easy to
ignore e.g. the lack of deployment of DNSSEC or more recently,
DoT.

> 
>> DoT is one way to tackle those problems. DoH is another.
> 
> DoT does not intend to place itself beyond interference by on-path entities, 
> and as such, my choice as a network operator is either to allow it through 
> even though i can't see the contents, or disallow it. and that's all fine.
> 
> DoH intends "to prevent on-path interference with DNS operations", and that's 
> well beyond the remit of RFC 7626, and is therefore not spoken to one way or 
> another by IETF consensus. i do not believe that a non-interference objective 
> would reach broader IETF consensus. perhaps we can test that one day.

Over the years, we've had quite a few people propose schemes to
provide integrity (and presumably hence prevent "interference")
but no confidentiality. (There's an ongoing discussion of the very
latest iteration of that on the TLS list in the last month or so.)
That leads me to guess that a position that "interference is ok
but confidentiality is not a problem" is not one that'd tend to
garner consensus. But as you say, maybe some day we'll test that
proposition.

Cheers,
S.


> 
> vixie
> 
> 
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Christian Huitema]

On 3/12/2019 11:35 AM, Paul Vixie wrote:

> if someone is concerned that some of the web sites 
> reachable through some CDN are dangerous...


Paul, who is this someone? How do they decide? What does dangerous mean?
These questions are very much behind the tension we see today. And the
answers are not as black and white as "this is my network, I get to decide".

For example, users routinely delegate the filtering decision to some
kind of security software running on their device, often with support
from some cloud based service. They are making an explicit decision, and
often use menu options to decide what type of site is OK or not --
adults would probably not subscribe to parental control services. There
is a market for these products, they compete based on reputation, ease
of use, etc.

You are saying that whoever happens to control part of the network path
is entitled to override the user choices and impose their own. Really?
As Stephane wrote, that may be legit in some circumstances, but much
more questionable in others, such as a hotel Wi-Fi attempting to decide
what sites I could or could not access. It really is a tussle.

-- Christian Huitema



___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Paul Vixie]

On Tuesday, 12 March 2019 18:56:05 UTC Christian Huitema wrote:
> On 3/12/2019 11:35 AM, Paul Vixie wrote:
> > if someone is concerned that some of the web sites
> > reachable through some CDN are dangerous...
> 
> Paul, who is this someone?

a network operator.

> How do they decide? What does dangerous mean?

that's a local policy matter, not subject to standardization, thus off-topic 
here.

> These questions are very much behind the tension we see today. And the
> answers are not as black and white as "this is my network, I get to decide".

if it is my network, i get to decide. that's what i told spammers when i 
started the first anti-spam company (MAPS) and co-invented the first 
distributed reputation protocol (RBL), 23 years ago. it remains true today.

my network, my rules. don't like my rules? use a different network.

> 
> For example, users routinely delegate the filtering decision to some
> kind of security software running on their device, often with support
> from some cloud based service. They are making an explicit decision, and
> often use menu options to decide what type of site is OK or not --
> adults would probably not subscribe to parental control services. There
> is a market for these products, they compete based on reputation, ease
> of use, etc.
> 
> You are saying that whoever happens to control part of the network path
> is entitled to override the user choices and impose their own. Really?

no. not really. not at all. because, as before, you are claiming to restate my 
position, but doing so erroneously.

> As Stephane wrote, that may be legit in some circumstances, but much
> more questionable in others, such as a hotel Wi-Fi attempting to decide
> what sites I could or could not access. It really is a tussle.

i don't like the chinese government's rules for the great firewall. so, i keep 
my visits to that otherwise-great country short. this hurts me, and maybe 
hurts them also. but, it's their country, and i will obey their laws when i am 
using their network. and then i'll vote with my feet, to get to a better 
network with better rules. i once traveled to HK for a weekend between two 
week-long conferences behind the GFW, just so i could get work done.

if you visit my home or office, you will either use my offered RDNS, or you 
will use an authorized VPN. so, beware. those are the rules. if you want 
different rules, use a different network.

vixie



___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Paul Vixie]

On Monday, 11 March 2019 21:44:06 UTC Eric Rescorla wrote:
> On Mon, Mar 11, 2019 at 11:13 AM Paul Vixie  wrote:
> > >  > Enterprise networks are already able to block DoH services,
> > 
> > i wonder if everyone here knows that TLS 1.3 and encrypted headers is
> > going to push a SOCKS agenda onto enterprises that had not previously
> > needed one,
> 
> I'm pretty familiar with TLS 1.3, but I don't know what this means. TLS 1.3
> doesn't generally encrypt headers any more than TLS 1.2 did, except for
> the content type byte, which isn't that useful for inspection anyway.
> Are you perchance referring to encrypted SNI? Something else?

yes, i mean encrypted SNI, and i apologize for saying "encrypted headers".

> encrypted SNI, an extension to the TLS 1.3 protocol that improves privacy of
> Internet users by preventing on-path observers, including ISPs, coffee shop
> owners and firewalls, from intercepting the TLS Server Name Indication
> (SNI) extension and using it to determine which websites users are
> visiting.

(https://blog.cloudflare.com/encrypted-sni/)

what this means is, if someone is concerned that some of the web sites 
reachable through some CDN are dangerous, they can no longer operate a mostly-
transparent edge gateway, to permit or forbid transactions on a case by case 
basis. rather, they will have to use SOCKS or similar, and blackhole the CDN 
from being reached other than from the SOCKS/similar proxy.

this significantly increases policy enforcement costs, probably placing them 
outside the budget of most small/medium companies, and all home networks.

and that's the intent. so:

> Enterprise networks are already able to block DoH services,

that's old-think.

vixie


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients

[Stephane Bortzmeyer]

On Tue, Mar 12, 2019 at 04:55:11PM +0100,
 Neil Cook  wrote 
 a message of 22 lines which said:

> Actually many enterprises (particularly banks etc.) do not allow DNS 
> resolution directly from employee endpoints.

They block UDP/53, which is not the same thing. Malware or
non-cooperating applications can do name resolution by other means. I
still do not understand why people have a problem with DoH whch did
not already exist before with
my-own-name-resolution-protocol-over-HTTPS.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Ralf Weber]

Moin!

On 12 Mar 2019, at 17:01, Stephane Bortzmeyer wrote:


On Tue, Mar 12, 2019 at 04:55:11PM +0100,
 Neil Cook  wrote
 a message of 22 lines which said:

Actually many enterprises (particularly banks etc.) do not allow DNS 
resolution directly from employee endpoints.


They block UDP/53, which is not the same thing.
Well the DNS protocol has been defined on UDP and TCP port 53, so if you 
block this, you block DNS. If you add TCP/853 into the mix you block DNS 
over TLS, all of which is relative easy for an enterprise to do.



Malware or
non-cooperating applications can do name resolution by other means. I
still do not understand why people have a problem with DoH whch did
not already exist before with
my-own-name-resolution-protocol-over-HTTPS.
A malware doing something specific to it is different than an IETF 
standard and application providers taking this standard (DoH) to switch 
a basic internet function (name lookups) without the users consent which 
are due to using HTTPs/443 harder to block for enterprises. It is a 
pretty clear difference.


So long
-Ralf
—--
Ralf Weber

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Brian Dickson]

On Tue, Mar 12, 2019 at 3:51 PM Paul Vixie  wrote:

> On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote:
> > On 12/03/2019 21:11, Paul Vixie wrote:
> > > ...
> >
> > There are reasons to want confidentiality for DNS queries
> > and answers, and access patterns, for which the IETF has
> > achieved consensus. (See RFC7626) (*)
>
> i have no qualms about confidentiality, for traffic allowed by a network
> operator. it's the inability to interefere (as called for in RFC 8484) and
> not
> the inability to observe (as called for in RFC 7626) that's at issue here.
>
> > DoT is one way to tackle those problems. DoH is another.
>
> DoT does not intend to place itself beyond interference by on-path
> entities,
> and as such, my choice as a network operator is either to allow it through
> even though i can't see the contents, or disallow it. and that's all fine.
>
>
I think there is a way to use technical design(s) to split hairs, i.e. I
think the side meeting
has the possibility of bearing fruit which is palatable enough for all
parties.

The crux of the problem is how to determine if the network operator is
truly hostile (GFC),
or merely restrictive (Paul's network, Paul's rules.)

Suppose the client signaled a desire to use a particular DoH operator.
The network could respond with, "No", or "Yes", or "Yes, but I want to
inspect your DNS traffic",
or "No, but I'll place you logically outside my network, and enable the
isolated bubble you are in to do what you want."
The client could treat "No" as hostile, and do something appropriate for
being behind the GFC.
The client could treat the "Yes, but" as a reason to then ask for the
"bubble" treatment.
If the client is offered and accepts, or requests and is permitted, the
"bubble" treatment, there is no need to go hostile.
In "bubble", the client would not be able to interact with any local
resources, in effect being in a non-split-mode VPN to the outside world.

There is really nothing that would stop a non-compliant client (or malware)
from choosing the "hostile" mode.
However, if "bubble" is available, I don't see why that would not be
acceptable for any client that isn't malicious.

Does "bubble" (and the signaling required) seem like a promising compromise?
(Presuming the operator can still refuse "bubble" requests, of course,
perhaps with a polite message denying the request with an explanation.)

(Also, I would expect the MDM thing can be reduced to whether client(s) are
allowed to go hostile or do "bubble" mode.)

Brian

Brian


> DoH intends "to prevent on-path interference with DNS operations", and
> that's
> well beyond the remit of RFC 7626, and is therefore not spoken to one way
> or
> another by IETF consensus. i do not believe that a non-interference
> objective
> would reach broader IETF consensus. perhaps we can test that one day.
>
> vixie
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Paul Vixie]

On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote:
> On 12/03/2019 21:11, Paul Vixie wrote:
> > ...
> 
> There are reasons to want confidentiality for DNS queries
> and answers, and access patterns, for which the IETF has
> achieved consensus. (See RFC7626) (*)

i have no qualms about confidentiality, for traffic allowed by a network 
operator. it's the inability to interefere (as called for in RFC 8484) and not 
the inability to observe (as called for in RFC 7626) that's at issue here.

> DoT is one way to tackle those problems. DoH is another.

DoT does not intend to place itself beyond interference by on-path entities, 
and as such, my choice as a network operator is either to allow it through 
even though i can't see the contents, or disallow it. and that's all fine.

DoH intends "to prevent on-path interference with DNS operations", and that's 
well beyond the remit of RFC 7626, and is therefore not spoken to one way or 
another by IETF consensus. i do not believe that a non-interference objective 
would reach broader IETF consensus. perhaps we can test that one day.

vixie


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Stephen Farrell]

On 12/03/2019 21:11, Paul Vixie wrote:
> he's trying to achieve a political aim using technology.

Ok, now I think I understand and am pretty sure I disagree
with you there.

There are reasons to want confidentiality for DNS queries
and answers, and access patterns, for which the IETF has
achieved consensus. (See RFC7626) (*)

DoT is one way to tackle those problems. DoH is another.
I think an argument that DoH is "just politics" and is
not aiming to try provided a security/privacy mechanism to
tackle a problem on which the IETF has consensus falls on
that basis myself.

I fully agree that there are potential DoH deployments
that could have side-effects (more that DoT) that warrant
more discussion, but I figure your arguments along the
above lines are misdirected.

Cheers,
S.

(*) Ironically, one of the arguments against DoH raised
in this discussion is that it would expose that kind of
information from split-horizon deployments, so it seems
that even those concerned about DoH accept the problem
statement, which is helpful.





0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Christian Huitema]

On 3/12/2019 12:56 PM, Paul Vixie wrote:
>> As Stephane wrote, that may be legit in some circumstances, but much
>> more questionable in others, such as a hotel Wi-Fi attempting to decide
>> what sites I could or could not access. It really is a tussle.
> i don't like the chinese government's rules for the great firewall. so, i 
> keep 
> my visits to that otherwise-great country short. this hurts me, and maybe 
> hurts them also. but, it's their country, and i will obey their laws when i 
> am 
> using their network. and then i'll vote with my feet, to get to a better 
> network with better rules. i once traveled to HK for a weekend between two 
> week-long conferences behind the GFW, just so i could get work done.


There is a lot of difference between what can be imposed in a police
state and what looks legitimate in a user agreement in a free country.
And I sure hope that we maintain that difference. A good result of that
discussion would be to clarify these differences. For example, there are
legal differences between what can be done in a private home, and what
can be done in a place like a hotel that provides public accommodation.
Just like hotels cannot discriminate against some categories of
customers, I don't think that places providing public connectivity
should be able to discriminate against content accessed by their guests.

-- Christian Huitema

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Paul Vixie]

On Tuesday, 12 March 2019 21:05:36 UTC Stephen Farrell wrote:
> Paul,
> 
> On 12/03/2019 20:51, Paul Vixie wrote:
> > just as i've cautioned the RFC 8484 authors against imposing their anti-
> > censorship views on my parental controls or corporate network policies,
> > let me here caution you against imposing your (clearly) western
> > liberal-democratic views on the development of protocols whose ideal
> > state is "interoperability" and never more or less.
> 
> I'm sorry but I don't understand this argument.
> 
> DoH interoperates pretty well.

but does it intend more, or less?

>... Two primary use cases were considered during this protocol's
>development.  These use cases are preventing on-path devices from
>interfering with DNS operations, ...

(from Introduction, RFC 8484.)

> 
> You and Christian have expressed different concerns not
> related to interop.

did you read what i wrote?

> 
> I don't see why, based on your argument, your concerns
> trump his.
> 
> Can you explain?

he's trying to achieve a political aim using technology. that is not the 
purpose for which the internet engineering task force, or the internet itself, 
was convened. it is not why our employers pay our travel costs. and it is not 
why the rest of the world trusts our outputs.


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Stephen Farrell]

Paul,

On 12/03/2019 20:51, Paul Vixie wrote:
> just as i've cautioned the RFC 8484 authors against imposing their anti-
> censorship views on my parental controls or corporate network policies, let 
> me 
> here caution you against imposing your (clearly) western liberal-democratic 
> views on the development of protocols whose ideal state is "interoperability" 
> and never more or less.

I'm sorry but I don't understand this argument.

DoH interoperates pretty well.

You and Christian have expressed different concerns not
related to interop.

I don't see why, based on your argument, your concerns
trump his.

Can you explain?

Thanks,
S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Paul Vixie]

On Tuesday, 12 March 2019 20:31:54 UTC Christian Huitema wrote:
> On 3/12/2019 12:56 PM, Paul Vixie wrote:

> > i don't like the chinese government's rules for the great firewall. so, i
> > keep my visits to that otherwise-great country short. this hurts me, and
> > maybe hurts them also. but, it's their country, and i will obey their
> > laws when i am using their network. and then i'll vote with my feet, to
> > get to a better network with better rules. i once traveled to HK for a
> > weekend between two week-long conferences behind the GFW, just so i could
> > get work done.

> There is a lot of difference between what can be imposed in a police
> state and what looks legitimate in a user agreement in a free country.
> And I sure hope that we maintain that difference.

i expect you to be disappointed in that hope, if you work on this long enough.

> A good result of that
> discussion would be to clarify these differences. For example, there are
> legal differences between what can be done in a private home, and what
> can be done in a place like a hotel that provides public accommodation.

there are also legal differences from nation to nation, from state to state, 
from county to county, and from city to city. the internet is below all of 
that.

> Just like hotels cannot discriminate against some categories of
> customers, I don't think that places providing public connectivity
> should be able to discriminate against content accessed by their guests.

just as i've cautioned the RFC 8484 authors against imposing their anti-
censorship views on my parental controls or corporate network policies, let me 
here caution you against imposing your (clearly) western liberal-democratic 
views on the development of protocols whose ideal state is "interoperability" 
and never more or less.

vixie



___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients

[Yishai Beeri (yishaib)]

On 12/03/2019, 20:37, "Doh on behalf of Stephane Bortzmeyer" 
 wrote:

On Tue, Mar 12, 2019 at 04:55:11PM +0100,
 Neil Cook  wrote 
 a message of 22 lines which said:

> Actually many enterprises (particularly banks etc.) do not allow DNS 
resolution directly from employee endpoints.

They block UDP/53, which is not the same thing. Malware or
non-cooperating applications can do name resolution by other means. I
still do not understand why people have a problem with DoH whch did
not already exist before with
my-own-name-resolution-protocol-over-HTTPS.

It is common practice for Malware operators to use bona fide DNS infrastructure 
(including resolvers) to communicate with the malware application. One useful 
example are DGAs [1]. This practice is cheaper and more robust for Malware 
operators than setting up their own DNS resolver service, not to mention 
implementing a proprietary protocol. It also helps isolate the malware operator 
from the malware as these communications all happen through legit services (all 
the malware operator has to do to trigger the resident malware is to register a 
domain).

DoH, and specifically the (intended) inability to distinguish DoH from other 
traffic, makes this practice much harder to detect and to block - which is why 
this a problem that did not already exist before.

[1] 
https://umbrella.cisco.com/blog/2016/10/10/domain-generation-algorithms-effective/

___
Doh mailing list
d...@ietf.org
https://www.ietf.org/mailman/listinfo/doh

Yishai

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Michael Sinatra]

On 3/12/19 9:14 AM, Jim Reid wrote:
> 
> 
>> On 12 Mar 2019, at 16:01, Stephane Bortzmeyer  wrote:
>>
>> I still do not understand why people have a problem with DoH whch did
>> not already exist before with my-own-name-resolution-protocol-over-HTTPS.
> 
> It’s a question of scale/ubiquity. These “alterate” resolution tricks have up 
> until now been mostly confined to a small number of clueful people. That is 
> going to change dramatically once the world’s web browsers and other 
> web-based apps start using DoH. More so if those platforms have DoH enabled 
> by default.

There's also a fundamental tension that arises when we define as
legitimate those practices that are indistinguishable (or hard to
distinguish) from what bad guys do.  Think of all of the HR departments
out there that send *legitimate* emails asking their employees to click
on a link to update/verify information.  DoH does this too and it
arguably goes a step further by effectively obfuscating DNS resolution
activity, so that legitimate users occupy the same "hideout" as the bad
guys.

This is one of the main themes of section 9 of draft-reid-doh-operator
and one of the main motivations in the recommendations of section 4 of
draft-bertola-bcp-doh-clients, but it bears restating because for those
of us trying to do risk mitigation, or even policy compliance, DoH gives
us additional headaches.

michael

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Paul Vixie]

On Tuesday, 12 March 2019 15:36:36 UTC Stephane Bortzmeyer wrote:
> On Mon, Mar 11, 2019 at 08:55:18AM +0530,
>  nalini elkins  wrote
> 
>  a message of 202 lines which said:
> > The questions that the Fortune 50 company architect asked were something
> > like this:
> > 
> > 1. You mean that DNS could be resolved outside my enterprise?
> 
> I suggest to explain to this person that it was possible before, as
> any malware author discovered.

no, it was not possible before. or rather, it could be cheaply prevented 
before.

> If people responsible for networks of Fortune 50 company don't know
> that it is difficult to stop unwanted communication (except when you
> control all the endpoints, or when you airgap your network), then it
> is indeed a problem :-)

in my own travels, i've met some fortune-level CISO's who had not yet been 
told that RDNS monitor/control bypass was now an internet standard, and that 
behavioural modeling based on TCP/443 endpoints was no longer practical. so, i 
urge greater efforts on getting the word out.

vixie


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Fwd: New Version Notification for draft-hzpa-dprive-xfr-over-tls-01.txt

[Tony Finch]

Sara Dickinson  wrote:
>
> A new draft has been submitted outlining using DNS-over-TLS for zone 
> transfers.

I've had a brief skim.

It's entirely driven by zone confidentiality, which is a fine thing, but
from my point of view the interesting possibility is to get transport
integrity (like TSIG) but with much simpler key management.

Single-ended public key authentication of the primary with IP-based
access control for secondaries should be an easy upgrade that do not
currently use TSIG, and really nice for stealth secondaries.

Double-ended public key auth will help reduce the need to break out gpg
for key exchange with oldskool third-party secondarying arrangements.

So I think this is interesting from the dnsop perspective as well as
dprive.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
an equitable and peaceful international order

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Paul Vixie]

On Tuesday, 12 March 2019 09:01:42 UTC Stephane Bortzmeyer wrote:
> On Mon, Mar 11, 2019 at 06:57:03PM +0100,
>  Vittorio Bertola  wrote
> 
>  a message of 18 lines which said:
> > Moreover, centralization is not the only Do*-related problem
> > category that has been raised (my draft alone lists eight others).
> 
> IMHO, this is precisely the biggest problem with these three drafts:
> they accumulate a lot of unrelated rants, and it is important to split
> between issues that are really DoH-specific from more general issues.

when you refer to something as a rant, you diminish and disrespect it.

any concern about the inability of a network operator to maintain possession 
of their RDNS control plane is on-topic for DoH, simply because RFC 8484's 
stated goal is to prevent on-path interference with DNS operations.

please do not relegate discussions about the loss of operator control over the 
RDNS control plane to some mailing list where DoH is not front-and-center. 
their intentions were clear. therefore they should participate in the results.

> 
> Warren Kumari did a good job of sorting that out in
> . I
> quote him:
> 
> 1: the protocol,
> 2: the deployment concerns,
> 3: "resolverless DNS",
> 4: the loss of visibility from encrypting the DNS

that is a useless distinction.

> 
> IMHO, this makes several side meetings. People are welcome to organize
> more.

in usenet, we used to say "please take this to some mailing list" by which we 
meant "...that i won't be joining, so that i no longer have to listen to you."

so far, most responses to RDNS control plane ownership issues have received a 
similar response. "please find someone who cares, and talk to them about it."

that's going to make the coming fight harder. we should be looking to make it 
easier.

vixie


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

[Christian Huitema]

On 3/12/2019 9:02 AM, Jim Reid wrote:
>
>> On 12 Mar 2019, at 15:49, Stephane Bortzmeyer  wrote:
>>
>> the case of a commercial
>> Internet access provider is clear in the other direction: a client is
>> not an employee, and is entitled to a free, open and neutral Internet
>> access.
> Stephane, that’s simply not true. A client of an Internet access provider is 
> entitled to the service that they contractually agreed to pay for. Check the 
> small print. Or the T the next time you use some coffeeshop’s wifi. Even 
> if your ISP offers you “free, open and neutral Internet access” (for some 
> definition of that phrase), I’m pretty sure they’ll drop your service if you 
> were damaging their network or or doing something else that was illegal or 
> otherwise in breach of their T


Jim, you are just providing a different interpretation of "entitled".
Your reading is that the fine print in the ISP contract limits what
users are entitled to do. Stephane is pointing out that customers expect
to be able to freely access whatever Internet resource they want,
regardless of the fine print. Courts have been called to decide that
sort of things, in particular for various "shrink wrap" software
licenses. The results vary. Sometimes the courts let the fine print
stand, some times they treat it as an abuse of power and nullify it.
Which points exactly to Stephane's characterization: it is a tussle.

-- Christian Huitema


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [EXTERNAL] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Eliot Lear]

Hi Tiru,

> On 12 Mar 2019, at 16:31, Konda, Tirumaleswar Reddy 
>  wrote:
> 
> MDM may or may not be acceptable even in Enterprise networks. For instance, 
> today network security services are using ML techniques to identify malware 
> flows without acting as a TLS proxy. MDM is also not an option to secure 
> devices in the home networks, especially consumer IoT devices.
> 


I agree that MDMs should not be viewed as a panacea.  Just a tool in the box.  
But this is why I wrote that text the way I did: there may be other ways to 
express in some secure way evidence of the owner’s intent.

Eliot



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Jim Reid]

> On 12 Mar 2019, at 16:01, Stephane Bortzmeyer  wrote:
> 
> I still do not understand why people have a problem with DoH whch did
> not already exist before with my-own-name-resolution-protocol-over-HTTPS.

It’s a question of scale/ubiquity. These “alterate” resolution tricks have up 
until now been mostly confined to a small number of clueful people. That is 
going to change dramatically once the world’s web browsers and other web-based 
apps start using DoH. More so if those platforms have DoH enabled by default.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients

[Neil Cook]

> On 12 Mar 2019, at 17:01, Stephane Bortzmeyer  wrote:
> 
> On Tue, Mar 12, 2019 at 04:55:11PM +0100,
> Neil Cook  wrote 
> a message of 22 lines which said:
> 
>> Actually many enterprises (particularly banks etc.) do not allow DNS 
>> resolution directly from employee endpoints.
> 
> They block UDP/53, which is not the same thing. Malware or
> non-cooperating applications can do name resolution by other means. I
> still do not understand why people have a problem with DoH whch did
> not already exist before with
> my-own-name-resolution-protocol-over-HTTPS.

Sure, but the malware has to go to a specific server which can be identified 
and blocked. For any companies implementing a “whitelist-only” security-policy, 
this is straightforward. Even without, these kinds of requests can be spotted 
as anomalies etc.

This is a different scenario then a DoH server co-located with e.g. youtube.com 
 or whatever, which is a little harder to block (by design 
as P. Vixie has pointed out).

Neil___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Eric Rescorla]

On Tue, Mar 12, 2019 at 8:51 AM Konda, Tirumaleswar Reddy <
tirumaleswarreddy_ko...@mcafee.com> wrote:

> Hi Eric,
>
>
>
> In TLS 1.2, it is possible for firewalls to inspect the TLS handshake, and
> white-list, black-list and grey-list TLS session based on the server
> identity. In other words, middleboxes are conditionally acting as TLS
> proxies to specific servers (categorized in the grey-list).
>
With TLS 1.3 and encrypted SNI, the middle box now has to act as a TLS
> proxy for all the flows.
>

It would be most useful not to conflate TLS 1.3 and ESNI.

In ordinary TLS 1.3, the SNI is in the clear but the server cert is not.
However, importantly, even in TLS 1.2, the server certificate is not
verifiable, and therefore is not significantly more trustworthy than SNI.

With ESNI, the SNI is encrypted (hence the name). However, the xpectation
is that enterprises which want to do conditional inspection will disable
ESNI on the client. This should not be problematic as they already need
access to the client to install their own trust anchor.

-Ekr



>
> -Tiru
>
>
>
> *From:* Eric Rescorla 
> *Sent:* Tuesday, March 12, 2019 3:14 AM
> *To:* Paul Vixie 
> *Cc:* nalini elkins ; Konda, Tirumaleswar Reddy
> ; d...@ietf.org; dn...@ietf.org;
> Ackermann, Michael ; Christian Huitema <
> huit...@huitema.net>; dns-privacy@ietf.org; Vittorio Bertola
> ; Stephen Farrell <
> stephen.farr...@cs.tcd.ie>
> *Subject:* Re: [Doh] [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.
> --
>
>
>
>
>
> On Mon, Mar 11, 2019 at 11:13 AM Paul Vixie  wrote:
>
>
>
> nalini elkins wrote on 2019-03-11 10:26:
> > Tiru,
> >
> > Thanks for your comments.
> >
> >  > Enterprise networks are already able to block DoH services,
> i wonder if everyone here knows that TLS 1.3 and encrypted headers is
> going to push a SOCKS agenda onto enterprises that had not previously
> needed one,
>
>
>
> I'm pretty familiar with TLS 1.3, but I don't know what this means. TLS 1.3
>
> doesn't generally encrypt headers any more than TLS 1.2 did, except for
>
> the content type byte, which isn't that useful for inspection anyway.
>
> Are you perchance referring to encrypted SNI? Something else?
>
>
>
> -Ekr
>
>
>
> and that simply blocking every external endpoint known or
> tested to support DoH will be the cheaper alternative, even if that
> makes millions of other endpoints at google, cloudflare, cisco, and ibm
> unreachable as a side effect?
>
> CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24, which i
> blocked already (before DoH) so that's not a problem. but if google
> decides to support DoH on the same IP addresses and port numbers that
> are used for some API or web service i depend on, that web service is
> going to be either blocked, or forced to go through SOCKS. this will add
> considerable cost to my network policy. (by design.)
>
> --
> P Vixie
>
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Neil Cook]

> On 12 Mar 2019, at 16:36, Stephane Bortzmeyer  wrote:
> 
> On Mon, Mar 11, 2019 at 08:55:18AM +0530,
> nalini elkins  wrote 
> a message of 202 lines which said:
> 
>> The questions that the Fortune 50 company architect asked were something
>> like this:
>> 
>> 1. You mean that DNS could be resolved outside my enterprise?
> 
> I suggest to explain to this person that it was possible before, as
> any malware author discovered.

Actually many enterprises (particularly banks etc.) do not allow DNS resolution 
directly from employee endpoints.

Neil
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Konda, Tirumaleswar Reddy]

Hi Eric,

In TLS 1.2, it is possible for firewalls to inspect the TLS handshake, and 
white-list, black-list and grey-list TLS session based on the server identity. 
In other words, middleboxes are conditionally acting as TLS proxies to specific 
servers (categorized in the grey-list).
With TLS 1.3 and encrypted SNI, the middle box now has to act as a TLS proxy 
for all the flows.

-Tiru

From: Eric Rescorla 
Sent: Tuesday, March 12, 2019 3:14 AM
To: Paul Vixie 
Cc: nalini elkins ; Konda, Tirumaleswar Reddy 
; d...@ietf.org; dn...@ietf.org; Ackermann, 
Michael ; Christian Huitema ; 
dns-privacy@ietf.org; Vittorio Bertola 
; Stephen Farrell 

Subject: Re: [Doh] [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.





On Mon, Mar 11, 2019 at 11:13 AM Paul Vixie 
mailto:p...@redbarn.org>> wrote:


nalini elkins wrote on 2019-03-11 10:26:
> Tiru,
>
> Thanks for your comments.
>
>  > Enterprise networks are already able to block DoH services,
i wonder if everyone here knows that TLS 1.3 and encrypted headers is
going to push a SOCKS agenda onto enterprises that had not previously
needed one,

I'm pretty familiar with TLS 1.3, but I don't know what this means. TLS 1.3
doesn't generally encrypt headers any more than TLS 1.2 did, except for
the content type byte, which isn't that useful for inspection anyway.
Are you perchance referring to encrypted SNI? Something else?

-Ekr

and that simply blocking every external endpoint known or
tested to support DoH will be the cheaper alternative, even if that
makes millions of other endpoints at google, cloudflare, cisco, and ibm
unreachable as a side effect?

CF has so far only supported DoH on 1.1.1.0/24 and 
1.0.1.0/24, which i
blocked already (before DoH) so that's not a problem. but if google
decides to support DoH on the same IP addresses and port numbers that
are used for some API or web service i depend on, that web service is
going to be either blocked, or forced to go through SOCKS. this will add
considerable cost to my network policy. (by design.)

--
P Vixie

___
Doh mailing list
d...@ietf.org
https://www.ietf.org/mailman/listinfo/doh
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

[Stephane Bortzmeyer]

On Sun, Mar 10, 2019 at 11:17:43PM -0700,
 Paul Vixie  wrote 
 a message of 36 lines which said:

> > You claim the right to impose your rules, because it is "your network".
> > Yet you have to define ownership.

> my network, my rules. your provider's network, their rules.

I clearly disagree. If the case of my home network (mine, my rules) is
clear, the case of a corporate network is less clear (an employee is
not a slave, and he/she has rights) and the case of a commercial
Internet access provider is clear in the other direction: a client is
not an employee, and is entitled to a free, open and neutral Internet
access.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 09:59:11AM +0530,
 nalini elkins  wrote 
 a message of 231 lines which said:

> Companies also (validly, in my opinion) wish to know if their
> employees are going to fantasyfootballgame.com while they are
> supposedly doing work and of course, other sites which people should
> not be going to during work time.  If I am paying someone, I expect
> them to do work that I wish them to do.

Not all companies work that way. Some evaluate the work done by the
results, not by the time spent at the desk. Please let's not discuss
IETF protocols while assuming that all companies are the same, and
that we have to endorse all their policies.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] New: draft-bertola-bcp-doh-clients

[Stephane Bortzmeyer]

On Sun, Mar 10, 2019 at 10:24:56PM -0700,
 Paul Vixie  wrote 
 a message of 82 lines which said:

> set up a war between end users and network operators,

Well, the tussle already exists. It does not depend on whether you
like it or not, on whether the IETF approves it or not. When people
have different interests, there is a tussle. What we can hope is to
discuss it in civilized ways. But we cannot make it disappear.

 

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 08:55:18AM +0530,
 nalini elkins  wrote 
 a message of 202 lines which said:

> The questions that the Fortune 50 company architect asked were something
> like this:
> 
> 1. You mean that DNS could be resolved outside my enterprise?

I suggest to explain to this person that it was possible before, as
any malware author discovered.

> 2. So whoever that is that resolves my DNS sees the pattern and frequency
> of what sites my company goes to?

RFC 7626 :-)

> It would be good to also discuss how to warn enterprises that this
> is about to happen.  I wonder if an announcement via CERT or another
> group may be appropriate.

If people responsible for networks of Fortune 50 company don't know
that it is difficult to stop unwanted communication (except when you
control all the endpoints, or when you airgap your network), then it
is indeed a problem :-)

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [EXTERNAL] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Konda, Tirumaleswar Reddy]

MDM may or may not be acceptable even in Enterprise networks. For instance, 
today network security services are using ML techniques to identify malware 
flows without acting as a TLS proxy. MDM is also not an option to secure 
devices in the home networks, especially consumer IoT devices.

Cheers,
-Tiru

From: dns-privacy  On Behalf Of Eliot Lear
Sent: Tuesday, March 12, 2019 7:34 PM
To: Winfield, Alister 
Cc: dn...@ietf.org; d...@ietf.org; dns-privacy@ietf.org
Subject: Re: [dns-privacy] [EXTERNAL] [Doh] [DNSOP] New: 
draft-bertola-bcp-doh-clients

Hi,


On 12 Mar 2019, at 14:11, Winfield, Alister 
mailto:alister.winfi...@sky.uk>> wrote:

MDM is also a red-herring given >90% of devices world-wide aren't managed so 
anyone talking of MDM riding to the rescue of DoH client configuration is 
walking around with blinkers on.

Firefox has published a specific policy interface just for this purpose.  I 
think the point, and perhaps others could correct me, is that the MDM serves as 
evidence that the owner of the device is authorizing a configuration change.  
And the use case I am discussing is the enterprise use case.  Your #s do not 
take that into account.


Even inside company networks there are servers not under MDM;

Servers seem an unlikely use of DoH from an application in particular.


locally developed applications that might in future pull in a DoH resolver;

In that case, the enterprise administrator is aiming the shotgun at his or her 
own foot.  I propose not to solve that problem, but rather to help them with 
tools to do the right thing.


BYOD; visitors; malware and so on.

It is certainly not best practice for visitors to be granted access to internal 
access; instead they typically are given guest access.

BYOD is a different story.  Here DoH may add pressure on those bringing their 
own devices to have to place them under MDM control.  That pressure already 
exists, by the way.  DoH just adds to it.



So whatever you think a reasonable solution for client configuration has to 
start with unmanaged clients. That last one malware is why the corporate 
response may well be 'MITM' the traffic so we can protect the data, people and 
systems using our network.

What DoH discovery and presentation looks like is complex issue that will take 
some discussion. Just one small example, I might want to use the local networks 
DNS if and only if it provides anti-malware protection and has a reasonable 
privacy policy but use a static one if not. Or perhaps on a child's device it's 
okay if there is filtering in place suitable for children.

I have previously written here that meaningful consent (a’la Sasse, Acquisti, 
et al) is a key issue.  With your example, Alister, you are essentially asking 
about number of attributes from the DNS server; some of which would have to be 
ascribed by others rather than simply self-asserted.  And then you have to make 
all of that information consumable and actionable by a normal person.  Good 
luck.

Just establishing an operational model in which split DNS is handled correctly 
will be enough of a challenge, but is worth exploring.

And that is why much of this smells like research to me.  If there are willing 
partners, I think that would be a great avenue to tread down.

Eliot


Alister

On 12/03/2019, 05:43, "dns-privacy on behalf of Konda, Tirumaleswar Reddy" 
mailto:dns-privacy-boun...@ietf.org> on behalf of 
tirumaleswarreddy_ko...@mcafee.com> 
wrote:


-Original Message-
From: Eliot Lear mailto:l...@cisco.com>>
Sent: Monday, March 11, 2019 11:49 PM
To: Paul Vixie mailto:p...@redbarn.org>>
Cc: nalini elkins mailto:nalini.elk...@e-dco.com>>; 
Konda, Tirumaleswar Reddy
mailto:tirumaleswarreddy_ko...@mcafee.com>>;
 d...@ietf.org; dn...@ietf.org;
Ackermann, Michael mailto:mackerm...@bcbsm.com>>; 
Christian Huitema
mailto:huit...@huitema.net>>; 
dns-privacy@ietf.org; Vittorio Bertola
mailto:vittorio.bertola=40open-xchange@dmarc.ietf.org>>;
 Stephen Farrell
mailto:stephen.farr...@cs.tcd.ie>>
Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

Hi Paul,


On 11 Mar 2019, at 19:12, Paul Vixie 
mailto:p...@redbarn.org>> wrote:



nalini elkins wrote on 2019-03-11 10:26:

Tiru,
Thanks for your comments.

Enterprise networks are already able to block DoH services,
i wonder if everyone here knows that TLS 1.3 and encrypted headers is
going to push a SOCKS agenda onto enterprises that had not previously
needed one, and that simply blocking every external endpoint known or
tested to support DoH will be the cheaper alternative, even if that makes
millions of other endpoints at google, cloudflare, cisco, and ibm unreachable
as a side effect?

That or it will require a bit more management at the MDM level.  I’m hoping
the latter.  And I hope that one output of all of these documents will be a
recommendation regarding MDM 

Re: [dns-privacy] [EXTERNAL] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Eliot Lear]

Hi,

> On 12 Mar 2019, at 14:11, Winfield, Alister  wrote:
> 
> MDM is also a red-herring given >90% of devices world-wide aren't managed so 
> anyone talking of MDM riding to the rescue of DoH client configuration is 
> walking around with blinkers on.

Firefox has published a specific policy interface just for this purpose.  I 
think the point, and perhaps others could correct me, is that the MDM serves as 
evidence that the owner of the device is authorizing a configuration change.  
And the use case I am discussing is the enterprise use case.  Your #s do not 
take that into account.

> Even inside company networks there are servers not under MDM;

Servers seem an unlikely use of DoH from an application in particular.

> locally developed applications that might in future pull in a DoH resolver;

In that case, the enterprise administrator is aiming the shotgun at his or her 
own foot.  I propose not to solve that problem, but rather to help them with 
tools to do the right thing.

> BYOD; visitors; malware and so on.

It is certainly not best practice for visitors to be granted access to internal 
access; instead they typically are given guest access.

BYOD is a different story.  Here DoH may add pressure on those bringing their 
own devices to have to place them under MDM control.  That pressure already 
exists, by the way.  DoH just adds to it.


> So whatever you think a reasonable solution for client configuration has to 
> start with unmanaged clients. That last one malware is why the corporate 
> response may well be 'MITM' the traffic so we can protect the data, people 
> and systems using our network.
> 
> What DoH discovery and presentation looks like is complex issue that will 
> take some discussion. Just one small example, I might want to use the local 
> networks DNS if and only if it provides anti-malware protection and has a 
> reasonable privacy policy but use a static one if not. Or perhaps on a 
> child's device it's okay if there is filtering in place suitable for children.

I have previously written here that meaningful consent (a’la Sasse, Acquisti, 
et al) is a key issue.  With your example, Alister, you are essentially asking 
about number of attributes from the DNS server; some of which would have to be 
ascribed by others rather than simply self-asserted.  And then you have to make 
all of that information consumable and actionable by a normal person.  Good 
luck.

Just establishing an operational model in which split DNS is handled correctly 
will be enough of a challenge, but is worth exploring.

And that is why much of this smells like research to me.  If there are willing 
partners, I think that would be a great avenue to tread down.

Eliot

> 
> Alister
> 
> On 12/03/2019, 05:43, "dns-privacy on behalf of Konda, Tirumaleswar Reddy" 
>  tirumaleswarreddy_ko...@mcafee.com> wrote:
> 
>> -Original Message-
>> From: Eliot Lear 
>> Sent: Monday, March 11, 2019 11:49 PM
>> To: Paul Vixie 
>> Cc: nalini elkins ; Konda, Tirumaleswar Reddy
>> ; d...@ietf.org; dn...@ietf.org;
>> Ackermann, Michael ; Christian Huitema
>> ; dns-privacy@ietf.org; Vittorio Bertola
>> ; Stephen Farrell
>> 
>> Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients
>> 
>> Hi Paul,
>> 
>>> On 11 Mar 2019, at 19:12, Paul Vixie  wrote:
>>> 
>>> 
>>> 
>>> nalini elkins wrote on 2019-03-11 10:26:
 Tiru,
 Thanks for your comments.
> Enterprise networks are already able to block DoH services,
>>> i wonder if everyone here knows that TLS 1.3 and encrypted headers is
>> going to push a SOCKS agenda onto enterprises that had not previously
>> needed one, and that simply blocking every external endpoint known or
>> tested to support DoH will be the cheaper alternative, even if that makes
>> millions of other endpoints at google, cloudflare, cisco, and ibm unreachable
>> as a side effect?
>> 
>> That or it will require a bit more management at the MDM level.  I’m hoping
>> the latter.  And I hope that one output of all of these documents will be a
>> recommendation regarding MDM interfaces.
> 
>I don't think MDM is required to use the DoT/DoH servers provided by the 
> local network.
> 
>-Tiru
> 
>> 
>> Eliot
>___
>dns-privacy mailing list
>dns-privacy@ietf.org
>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacydata=02%7C01%7Calister.winfield%40sky.uk%7Cab5faa933f374ae7b72c08d6a6ada348%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636879662059337184sdata=bba3bapIO3ffilylhoIj0x3zVkHYlNC4Gid96Ybx9Xo%3Dreserved=0
>
>This email is from an external source. Please do not open attachments or 
> click links from an unknown or suspicious origin. Phishing attempts can be 
> reported by sending them to phish...@sky.uk as attachments. Thank you
>

Re: [dns-privacy] [EXTERNAL] Re: [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Winfield, Alister]

MDM is also a red-herring given >90% of devices world-wide aren't managed so 
anyone talking of MDM riding to the rescue of DoH client configuration is 
walking around with blinkers on. Even inside company networks there are servers 
not under MDM; locally developed applications that might in future pull in a 
DoH resolver; BYOD; visitors; malware and so on. So whatever you think a 
reasonable solution for client configuration has to start with unmanaged 
clients. That last one malware is why the corporate response may well be 'MITM' 
the traffic so we can protect the data, people and systems using our network.

What DoH discovery and presentation looks like is complex issue that will take 
some discussion. Just one small example, I might want to use the local networks 
DNS if and only if it provides anti-malware protection and has a reasonable 
privacy policy but use a static one if not. Or perhaps on a child's device it's 
okay if there is filtering in place suitable for children.

Alister

On 12/03/2019, 05:43, "dns-privacy on behalf of Konda, Tirumaleswar Reddy" 
 
wrote:

> -Original Message-
> From: Eliot Lear 
> Sent: Monday, March 11, 2019 11:49 PM
> To: Paul Vixie 
> Cc: nalini elkins ; Konda, Tirumaleswar Reddy
> ; d...@ietf.org; dn...@ietf.org;
> Ackermann, Michael ; Christian Huitema
> ; dns-privacy@ietf.org; Vittorio Bertola
> ; Stephen Farrell
> 
> Subject: Re: [Doh] [dns-privacy] [DNSOP] New: 
draft-bertola-bcp-doh-clients
>
> Hi Paul,
>
> > On 11 Mar 2019, at 19:12, Paul Vixie  wrote:
> >
> >
> >
> > nalini elkins wrote on 2019-03-11 10:26:
> >> Tiru,
> >> Thanks for your comments.
> >> > Enterprise networks are already able to block DoH services,
> > i wonder if everyone here knows that TLS 1.3 and encrypted headers is
> going to push a SOCKS agenda onto enterprises that had not previously
> needed one, and that simply blocking every external endpoint known or
> tested to support DoH will be the cheaper alternative, even if that makes
> millions of other endpoints at google, cloudflare, cisco, and ibm 
unreachable
> as a side effect?
>
> That or it will require a bit more management at the MDM level.  I’m 
hoping
> the latter.  And I hope that one output of all of these documents will be 
a
> recommendation regarding MDM interfaces.

I don't think MDM is required to use the DoT/DoH servers provided by the 
local network.

-Tiru

>
> Eliot
___
dns-privacy mailing list
dns-privacy@ietf.org

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacydata=02%7C01%7Calister.winfield%40sky.uk%7Cab5faa933f374ae7b72c08d6a6ada348%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636879662059337184sdata=bba3bapIO3ffilylhoIj0x3zVkHYlNC4Gid96Ybx9Xo%3Dreserved=0

This email is from an external source. Please do not open attachments or 
click links from an unknown or suspicious origin. Phishing attempts can be 
reported by sending them to phish...@sky.uk as attachments. Thank you




Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trademarks of Sky Limited and Sky International AG 
and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited 
(Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 
2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect 
subsidiaries of Sky Limited (Registration No. 2247735). All of the companies 
mentioned in this paragraph are incorporated in England and Wales and share the 
same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

[Neil Cook]

>> 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.

Neil

> On 12 Mar 2019, at 06:14, Konda, Tirumaleswar Reddy 
>  wrote:
> 
>> -Original Message-
>> From: Stephen Farrell > >
>> Sent: Tuesday, March 12, 2019 5:30 AM
>> To: Paul Vixie mailto:p...@redbarn.org>>; d...@ietf.org 
>> 
>> Cc: nalini elkins > >; Konda, Tirumaleswar Reddy
>> > >; dn...@ietf.org 
>> ; Ackermann,
>> Michael mailto:mackerm...@bcbsm.com>>; Christian 
>> Huitema
>> mailto:huit...@huitema.net>>; dns-privacy@ietf.org 
>> ; Vittorio Bertola
>> > >
>> 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) 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
> dn...@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Vittorio Bertola]

> Il 12 marzo 2019 alle 10.01 Stephane Bortzmeyer  ha 
> scritto:
> 
> 
> On Mon, Mar 11, 2019 at 06:57:03PM +0100,
>  Vittorio Bertola  wrote 
>  a message of 18 lines which said:
> 
> > Moreover, centralization is not the only Do*-related problem
> > category that has been raised (my draft alone lists eight others).
> 
> IMHO, this is precisely the biggest problem with these three drafts:
> they accumulate a lot of unrelated rants, 

They are not unrelated, they are all effects of the same thing and you cannot 
deal with them separately, as some practices that would address one of the 
problems could worsen some of the others. Also, the fact that some of these are 
not problems for you does not imply that they are not problems for others, and 
if you want to get consensus, you have to address everyone's concerns and not 
just yours.

Also, the reason why this is a difficult problem is exactly that it affects 
many things at once. It is fine to break down the analysis into single issues, 
but when it comes to what to do next, if you start several parallel work 
threads without any clear coordination plan, you will just end up with several 
conflicting proposals.

So, rather than focusing on any specific entry of the list of issues, I think 
that the most urgent thing to discuss would be where to have the discussion (so 
that we can stop crossposting entire threads to four groups) and how to 
organize it (objectives, working items etc.).

Ciao,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Stephane Bortzmeyer]

On Tue, Mar 12, 2019 at 08:14:49PM +1100,
 Mark Nottingham  wrote 
 a message of 32 lines which said:

> I'm also very conscious that we had a side meeting about similar
> issues in Singapore (IIRC), and didn't make much progress at all in
> that time.

This time, we have drafts (poor ones, IMHO, but it's better than a
discussion without written proposals).

> Are we going to be able to productively use two hours for this?
> Could we come up with a more focused agenda and just use an hour?

You are the first to suggest to focus, until now, all remarks (both on
and off-list) have been people asking to *enlarge* the agenda :-)

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Mark Nottingham]

Hi,

I'm already starting to pile up conflicts on Wednesday. I'm also very conscious 
that we had a side meeting about similar issues in Singapore (IIRC), and didn't 
make much progress at all in that time. Are we going to be able to productively 
use two hours for this? Could we come up with a more focused agenda and just 
use an hour?

Cheers,
 

> On 12 Mar 2019, at 7:57 pm, Stephane Bortzmeyer  wrote:
> 
> On Mon, Mar 11, 2019 at 01:59:25PM -0400,
> Allison Mankin  wrote 
> a message of 94 lines which said:
> 
>> Perfect idea, very good use of the Wednesday slot.
> 
> New date and place registered at
> ,
> wednesday, Karlin 1/2, 1500 to 1700. (Note there is registry lock side
> meeting just before, for domain name industry people.)
> 
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh

--
Mark Nottingham   https://www.mnot.net/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 06:57:03PM +0100,
 Vittorio Bertola  wrote 
 a message of 18 lines which said:

> Moreover, centralization is not the only Do*-related problem
> category that has been raised (my draft alone lists eight others).

IMHO, this is precisely the biggest problem with these three drafts:
they accumulate a lot of unrelated rants, and it is important to split
between issues that are really DoH-specific from more general issues.

Warren Kumari did a good job of sorting that out in
. I
quote him:

1: the protocol,
2: the deployment concerns,
3: "resolverless DNS",
4: the loss of visibility from encrypting the DNS

IMHO, this makes several side meetings. People are welcome to organize
more.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 01:59:25PM -0400,
 Allison Mankin  wrote 
 a message of 94 lines which said:

> Perfect idea, very good use of the Wednesday slot.

New date and place registered at
,
wednesday, Karlin 1/2, 1500 to 1700. (Note there is registry lock side
meeting just before, for domain name industry people.)

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-spki-in-ns-name-00.txt

[A. Schulze]

manu tman:


What I meant is roughly around the line of
https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01#section-2
. e.g if you operate a resolver in strict mode, and DoT fails (connection
to port 853, fail to validate SPKI) while the name of the name server
indicates that DoT is supported. The resolver should fail.
In opportunistic mode, the resolver will fallback onto port 53. The
operator of the resolver will be setting the mode of operation.


Hello,

Ah, that makes sense, my reading was to allow the resolver to use 853  
in oportunistic mode even when SPKI validation fail. I've to reread  
the text...


Andreas



___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy