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

[Konda, Tirumaleswar Reddy]

> -Original Message-
> From: Stephen Farrell 
> Sent: Tuesday, March 12, 2019 5:30 AM
> To: Paul Vixie ; d...@ietf.org
> Cc: nalini elkins ; Konda, Tirumaleswar Reddy
> ; dn...@ietf.org; Ackermann,
> Michael ; Christian Huitema
> ; 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.
___
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

[Stephen Farrell]

On 12/03/2019 01:54, nalini elkins wrote:
> Stephen,
> 
>> TLS1.3 will, I expect, noticeably improve security for an awful lot of
>> enterprises in time.
> 
> I am sure you are right. 

Great.

> There is also likely to be quite a bit of pain
> ahead for many. 

I don't agree at all about that, despite claims to the
contrary from you and some others. But that topic was debated
at length already. (Seriously, do you expect some other outcome
if you re-start that debate?)

> Also,
> this is exactly why I propose a neutral observer who might tease out the
> nuances.  

I think that's an outstandingly bad idea. The IETF has no
voting and hence no electorate nor constituency and hence
no identifiable non-voting population from whom ostensibly
neutral observers could be chosen via some (currently
non-existent) IETF process. In addition to be just being a
bad idea, what you appear to be suggesting seems to me like
it'd require fundamental change to the core of the IETF and
to also be entirely off topic for the subject line of this
mail.

S.

> Or
> say something along the lines of "if you do x, you will need to do y".  It
> may also be
> needed to have subtopics.   And, the pro and con sides could also provide a
> writeup.
> The write up could also propose transition strategies.
> 
> I am trying to make it so that people, including enterprises, can better
> decide the merits of the
> situation for themselves.
> 
> Many people do not have the time, expertise or energy to follow these
> discussions which
> have gone on for a number of years.  I have also seen assessments of
> protocol changes from people
> who have "a dog in the hunt" so to speak.  That is, vendors who provide an
> assessment which
> (shockingly enough) results in their own products (which again shockingly,
> cost money) being the best
> solution.  There is much hyperbole on all sides of not just the TLS1.3
> issue but DoH also.
> 
> I compliment the authors of the current drafts on DoH deployment drafts for
> good efforts to bring
> light to this subject.
> 
> Having said that, I would like to see IETF work with a neutral third party,
> maybe an academic institution,
> or CERT, or someone else help people, including enterprise operators, who
> have to make decisions to
> implement these protocols and possibly change their architecture
> strategies.  Even if we manage to
> come to consensus on an IETF draft and create an RFC on DoH deployment,
> many enterprises do not
> keep up with all RFCs nor do they always have the time to evaluate
> everything properly because they
> are so busy with the fires of the current day.   I worked for large
> enterprises for many years doing network
> design and troubleshooting.  I was always extremely busy fighting the
> issues of the day.
> 
> Enterprises, and many others, do pay attention to what NIST or CERT says.
>  Just my 2 cents to try
> to find a long term solution to what has been a contentious and exhausting
> multi-year set of discussions
> for all involved and which seems set to rekindle with DoH.
> 
> Nalini
> 
> On Tue, Mar 12, 2019 at 5:30 AM Stephen Farrell 
> wrote:
> 
>>
>> (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.)
>>
>> Cheers,
>> S.
>>
> 
> 
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
> 


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] New Version Notification for draft-bretelle-dprive-dot-spki-in-ns-name-00.txt

[manu tman]

Thanks Andreas,

> what's the reason for "In opportunistic mode, the resolver MUST use the
authoritative name server despite the failure." ?
> A server operator can't distinguish between a resolver in strict mode an
a resolver in opportunistic mode TOGETHER with a failure (on server side?)
> An other option is to force any resolver supporting "dot-" names to fall
back on port 53.

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.

Thanks,
Manu

On Mon, Mar 11, 2019 at 12:12 PM A. Schulze  wrote:

>
>
> Am 11.03.19 um 17:20 schrieb manu tman:
> > I have captured in a draft the mechanism I used during IETF 103
> hackathon and which is available aan experimental module in
> knot-resolver[0].
> >  I was taken short with time before cit-off date, but I hope this will
> better explain how it works.
>
> Hello,
>
> for many years I run a dnscurve proxy [1] infront of my nameservers.
> Worked perfect but virtually nobody used the encryption feature.
> So, the draft *is* interesting to me...
>
> two points comes to my mind while reading the draft:
>
> 1.
> key rotation is hard.
>
> 2.
> what's the reason for "In opportunistic mode, the resolver MUST use the
> authoritative name server despite the failure." ?
> A server operator can't distinguish between a resolver in strict mode an a
> resolver in opportunistic mode TOGETHER with a failure (on server side?)
> An other option is to force any resolver supporting "dot-" names to fall
> back on port 53.
>
> Andreas
>
> [1] http://curvedns.on2it.net/
>
> ___
> 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] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Paul Vixie]

That's what they told me.

On Mar 11, 2019, 14:20, at 14:20, Daniel Stenberg  wrote:
>On Mon, 11 Mar 2019, Paul Vixie wrote:
>
>> CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24
>
>If that's what you believe and block, then you're not blocking
>Cloudflare DoH
>very effectively... =)
>
>--
>
>  / daniel.haxx.se
___
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 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] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

[Daniel Stenberg]

On Mon, 11 Mar 2019, Paul Vixie wrote:


CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24


If that's what you believe and block, then you're not blocking Cloudflare DoH 
very effectively... =)


--

 / daniel.haxx.se

___
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]

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.

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] New: draft-bertola-bcp-doh-clients

[Stephen Farrell]

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

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] New: draft-bertola-bcp-doh-clients

[Brian Dickson]

(Apologies for top-replying)

I think, from squinting at this a bit, that what is missing is some kind of
policy/service discovery, and coming to some kind of agreement (between
DNSOP and DOH, and any/all other interested parties) on what default
behavior should be (and under what conditions/circumstances), e.g. with
respect to opt-in vs opt-out.

E.g. If the local network operator is giving out addresses using DHCP or
the equivalent, then the presence/absence of DNS options in the answers,
should to some degree dictate (permitted) behavior.
And similarly, having some kind of DoH signaling incorporated in the DHCP
options, would be a sensible analogous mechanism.
E.g. "I will allow you to request DoH using providers X, Y, and Z, but
insist on being a MITM for those connections", or "Go ahead and do DoH to
any of these providers X, Y, Z, but no others", or "DoH is prohibited here,
use DNS", or "You can use DoT to these providers, DoH with me as MITM, or
this DNS resolver, but you can't run your own resolver".

Not sure what other mechanisms might be worth considering as alternatives
(dns-sd of some flavor)...

The mechanisms definitely to be a lot cleaner, more transparent, and
configurable, for both clients, network operators, and possibly DoT/DoH
operators.

(Did we learn nothing from the dial-up ISP early days, with mailing out
physical CD ROMs with phone numbers in lists and browsers included?)

Brian

On Sun, Mar 10, 2019 at 11:17 PM Paul Vixie  wrote:

>
>
> Christian Huitema wrote on 2019-03-10 23:05:
> > On 3/10/2019 10:24 PM, Paul Vixie wrote:
> >
> >> if you are using my network, then it makes no difference which of us
> >> bought you that laptop. you will use the RDNS i allow you to use. RDNS
> >> is part of the control plane, and i use it for both monitoring and
> >> control. sometimes that's so that i can see malware beacon to its C
> >> sometimes that's so that i can institute parental controls.
> >>
> >> if you don't like my rules, you should vote with your feet, and not
> >> visit me. because that is the only choice you will have. (yes, i will
> >> be part of a major new project to identify and block all DoH services,
> >> so that behavioural security policies can still work, because you may
> >> have noticed that the internet has never become MORE secure from new
> >> tech, but it occasionally becomes LESS secure more slowly because of
> >> policy.)
> >
> >
> > "Use a VPN, or use the local defaults".
>
> that is not what i said.
>
> > Well, there are plenty of
> > in-between.
>
> yes, and i gave examples.
>
> see above.
>
> > You claim the right to impose your rules, because it is "your network".
> > Yet you have to define ownership. You are providing network services
> > under some contractual terms. There are cases where an imperial network
> > can dictate those terms, but there are also many cases in which the
> > contractual power of the network is limited  -- thinks like fair access,
> > network neutrality, etc. Just claiming an empire does not automatically
> > make you the emperor.
>
> my network, my rules. your provider's network, their rules. they are
> more likely to have to follow their government's laws of commerce and
> privacy than i am likely to have to follow mine. but if the rules your
> network operator can make allow you to do what you want, use that
> network. that's invariant, for all networks, and for all instances of you.
>
> --
> P 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] New: draft-bertola-bcp-doh-clients

[nalini elkins]

>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 have, ahem, some familiarity with the enterprises and TLS1.3 issue.
(These
past few years have aged me terribly!)  I frankly feel that we have at the
IETF
a problem with the how we do conflict resolution and the process of
consensus
itself.  In fact, I co-authored a draft on this topic:

https://tools.ietf.org/html/draft-elkschul-conflict-problem-00

I feel that until we fix these fundamental issues, we will find ourselves
in this
place again and again.   The next time will be with QUIC (as Paul points out
in his mention of encrypted headers).  I actually have some suggestions as
to how we might better work with each other.  But, I do not want to
sidetrack
into a much larger issue.

At a minimum, I think that some relatively neutral arbiter, say CERT, might
provide an after the fact impact assessment that certain changes such as
DoH and TLS1.3 will have on enterprises, the home user, and so on.   Of
course, it would be better if such a neutral assessment were done BEFORE
the draft becomes final.

This is similar to what is done in California on ballot initiatives.  When
we get our
voting pamphlet, it tells us for each issue, what impact a pro or con vote
will have
on various aspects such as increased taxes, and so forth.

Nalini

On Mon, Mar 11, 2019 at 11:42 PM 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?
>
> 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
>
>

-- 
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] New Version Notification for draft-bretelle-dprive-dot-spki-in-ns-name-00.txt

[A. Schulze]

Am 11.03.19 um 17:20 schrieb manu tman:
> I have captured in a draft the mechanism I used during IETF 103 hackathon and 
> which is available aan experimental module in knot-resolver[0].
>  I was taken short with time before cit-off date, but I hope this will better 
> explain how it works.

Hello,

for many years I run a dnscurve proxy [1] infront of my nameservers.
Worked perfect but virtually nobody used the encryption feature.
So, the draft *is* interesting to me...

two points comes to my mind while reading the draft:

1.
key rotation is hard.

2.
what's the reason for "In opportunistic mode, the resolver MUST use the 
authoritative name server despite the failure." ?
A server operator can't distinguish between a resolver in strict mode an a 
resolver in opportunistic mode TOGETHER with a failure (on server side?)
An other option is to force any resolver supporting "dot-" names to fall back 
on port 53.

Andreas

[1] http://curvedns.on2it.net/

___
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

[Paul Vixie]

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?


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

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

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

[Sara Dickinson]

Hi All, 

A new draft has been submitted outlining using DNS-over-TLS for zone transfers.

The draft is quite basic at this stage but we are planning to work on this 
topic at the Hackathon to try to answer the open questions and move this 
forward.

Regards

Sara. 

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-hzpa-dprive-xfr-over-tls-01.txt
> Date: 11 March 2019 at 17:58:31 GMT
> To: "Sara Dickinson" , "Han Zhang" , 
> "Willem Toorop" , "Allison Mankin" 
> , "Pallavi Aras" 
> 
> 
> A new version of I-D, draft-hzpa-dprive-xfr-over-tls-01.txt
> has been successfully submitted by Sara Dickinson and posted to the
> IETF repository.
> 
> Name: draft-hzpa-dprive-xfr-over-tls
> Revision: 01
> Title:DNS Zone Transfer over TLS
> Document date:2019-03-11
> Group:Individual Submission
> Pages:8
> URL:
> https://www.ietf.org/internet-drafts/draft-hzpa-dprive-xfr-over-tls-01.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-hzpa-dprive-xfr-over-tls/
> Htmlized:   https://tools.ietf.org/html/draft-hzpa-dprive-xfr-over-tls-01
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-hzpa-dprive-xfr-over-tls
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-hzpa-dprive-xfr-over-tls-01
> 
> Abstract:
>   DNS zone transfers are transmitted in clear text, which gives
>   attackers the opportunity to collect the content of a zone by
>   eavesdropping on network connections.  The DNS Transaction Signature
>   (TSIG) mechanism is specified to restrict direct zone transfer to
>   authorized clients only, but it does not add confidentiality.  This
>   document specifies use of DNS-over-TLS to prevent zone contents
>   collection via passive monitoring of zone transfers.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

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

[Allison Mankin]

Perfect idea, very good use of the Wednesday slot.



On Mon, 11 Mar 2019 at 13:57, Vittorio Bertola  wrote:

> > Il 11 marzo 2019 alle 18.02 Stephane Bortzmeyer  ha
> scritto:
> >
> > It was suggested Reference necessary to have a
> > side meeting in Prague at IETF 104. I propose monday, 1400-1600 in
> > Tyrolka. The proposal is at
> > . You
> > are welcome to agree/disagree/meet in a bar instead.
>
> Why not in the Wednesday timeslot that was specifically set aside for side
> meetings? Also, I'm wondering whether a 40-people room is enough (may be,
> may be not).
>
> Moreover, centralization is not the only Do*-related problem category that
> has been raised (my draft alone lists eight others). So the focus of the
> meeting should be on whether, where and how to deal with all of them,
> though some of them may later be deemed off mission for the IETF. But first
> of all we need to agree on a venue and process.
>
> Ciao,
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
> ___
> hrpc mailing list
> h...@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>
___
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

[Vittorio Bertola]

> Il 11 marzo 2019 alle 18.02 Stephane Bortzmeyer  ha 
> scritto:
> 
> It was suggested Reference necessary to have a
> side meeting in Prague at IETF 104. I propose monday, 1400-1600 in
> Tyrolka. The proposal is at
> . You
> are welcome to agree/disagree/meet in a bar instead.

Why not in the Wednesday timeslot that was specifically set aside for side 
meetings? Also, I'm wondering whether a 40-people room is enough (may be, may 
be not).

Moreover, centralization is not the only Do*-related problem category that has 
been raised (my draft alone lists eight others). So the focus of the meeting 
should be on whether, where and how to deal with all of them, though some of 
them may later be deemed off mission for the IETF. But first of all we need to 
agree on a venue and process.

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] [hrpc] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Allison Mankin]

I'd appreciate it not conflicting with IRTFOPEN.  The ANRP topics include
how Facebook manipulates routing and a big study on QUIC, and I think there
should be participant overlap.

On Mon, 11 Mar 2019 at 13:22, Melinda Shore 
wrote:

> On 3/11/19 9:13 AM, Stephane Bortzmeyer wrote:
> > I admit I'm not sure that Secdispatch is so important here. The
> > subject of the side meeting is not security-specific.
>
> It also conflicts with irtfopen, which may impact the
> availability of pearg people, hrpc folk, etc.
>
> Melinda
>
> --
> Software longa, hardware brevis
>
> PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
>  34C0 DFB8 9172 9A76 DB8F
>
> ___
> 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] New: draft-bertola-bcp-doh-clients

[nalini elkins]

Tiru,

Thanks for your comments.

> Enterprise networks are already able to block DoH services,

We are also concerned about getting threat intelligence so that would
impact DoH on the Internet.   We are also concerned about being able to
block malware, etc. inside the enterprise.

Thank you for doing your draft.  I look forward to understanding it
better.  I believe it is a good start to address some of our potential
problems.  I am thinking over what the deployment and roll out strategies
might be in various topologies.  I will say more once I have thought it out.

Nalini

On Mon, Mar 11, 2019 at 8:37 PM Konda, Tirumaleswar Reddy <
tirumaleswarreddy_ko...@mcafee.com> wrote:

> Please see inline [TR]
>
>
>
> *From:* dns-privacy  *On Behalf Of *nalini
> elkins
> *Sent:* Monday, March 11, 2019 11:05 AM
> *To:* Paul Vixie 
> *Cc:* Stephen Farrell ; d...@ietf.org;
> dn...@ietf.org; Christian Huitema ;
> dns-privacy@ietf.org; Vittorio Bertola  40open-xchange@dmarc.ietf.org>; Ackermann, Michael <
> mackerm...@bcbsm.com>
> *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.
> --
>
> Paul,
>
>
>
> > (yes, i will be part of a major new project to identify and block all
> DoH services, so
>
> > that behavioural security policies can still work, because you may have
> > noticed that the internet has never become MORE secure from new tech,
> > but it occasionally becomes LESS secure more slowly because of policy.)
>
>
>
> I would be very interested, if you are so inclined, to hear more of what
> you are thinking.   Is this something you can (are willing to) talk about?
>
>
>
>
> [TR] Enterprise networks are already able to block DoH services, it is
> causing the DoH client to fallback to clear-text DNS compromising endpoint
> security and privacy. In draft
> https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-01 we
> are proposing mechanisms to automatically bootstrap endpoints to discover
> and authenticate privacy-enabling DNS servers provided by the Enterprise
> network.
>
>
>
> The user also gets to know the privacy preserving data policy by the DNS
> server and can decide whether to switch to another network or if the user
> trusts the network and privacy policy, the user can enable strict privacy
> profile with the privacy enabling DNS server discovered in the Enterprise
> network itself instead of downgrading to opportunistic privacy profile.
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> It sounds like a very thought-provoking initiative.
>
>
>
> Thanks,
>
> Nalini
>
>
>
> On Mon, Mar 11, 2019 at 10:55 AM Paul Vixie  wrote:
>
>
>
> Christian Huitema wrote on 2019-03-10 21:14:
> 
> > There are a bunch of conflicting requirements here, and it would be good
> > to tease out the contradictions. Consider the following cases:
> >
> > 1) I am using my phone, and using application-X.
> >
> > 2) I am at home, using application-X on my home computer.
> >
> > 3) I am using Wi-Fi in a hotel, and using application-X.
> >
> > 4) I am using my work laptop on the enterprise network, and using
> > application-X
> >
> > 5) I am using my work laptop in a hotel, and using application-X
> >
> > 6) I am using my work laptop on the network of a customer, and using
> > application-X.
>
> this distinction is not useful.
>
> there are two cases.
>
> a user or app trusts its network.
>
> or not.
>
> in the first case, you'll use an RDNS service which is in the set
> (allowed (preferred)). that is, you'll use the server you desire most
> out of the set that your network operator allows you to reach.
>
> in the second case, you'll use a VPN, for all of your traffic, not just
> for DNS, because if you hide your DNS but not the connections which
> result from such hiding, it will add no measurable privacy.
>
> > Today, plenty of people claim the right to control how I use the DNS: my
> > phone carrier, my ISP at home, the company that got the contract to
> > manage the hotel's Wi-Fi, the IT manager for my company's laptop, the IT
> > manager for the company that I am visiting. Out of those, there is just
> > one scenario for which the claim has some legitimacy: if the company
> > pays for my laptop and own the laptop, yes of course it has a legitimate
> > claim to control how I am using it. Otherwise, I, the user, get to
> > decide. If I like the application's setting better than the network's
> > default, then of course I expect those settings to stick.
>
> this distinction is also false.
>
> if you are using my network, then it makes no difference which of us
> bought you that laptop. you will use the RDNS i allow you to use. RDNS
> is part of the control plane, and i use it for both monitoring and
> control. sometimes that's so that i can see malware beacon to its C
> sometimes that's so that i can institute parental controls.
>
> if you 

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

[Melinda Shore]

On 3/11/19 9:13 AM, Stephane Bortzmeyer wrote:
> I admit I'm not sure that Secdispatch is so important here. The
> subject of the side meeting is not security-specific.

It also conflicts with irtfopen, which may impact the
availability of pearg people, hrpc folk, etc.

Melinda

-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

___
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

[Ted Hardie]

On Mon, Mar 11, 2019 at 10:13 AM Stephane Bortzmeyer 
wrote:

> On Mon, Mar 11, 2019 at 10:06:21AM -0700,
>  Ted Hardie  wrote
>  a message of 76 lines which said:
>
> > This conflicts with SECDISPATCH, which will have a pretty serious impact
> on
> > who might attend.  Scheduling these things is very hard, obviously. Given
> > this topic, you may have to move outside the normal agenda time to get a
> > reasonable shot at avoiding conflict.
>
> I avoided conflicts with doh, dprive, dnsop and hrpc but avoiding all
> conflicts is close-to-impossible. In the evening, people have
> meetings, too.
>
> I admit I'm not sure that Secdispatch is so important here. The
> subject of the side meeting is not security-specific.
>

It is certainly not only about security, but there are several important
security trade-offs in play with these choices.  Secdispatch pulls pretty
much the entire Security Area, and a conflict seems to me personally very
unfortunate in its scope.

regards,

Ted
___
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 Mon, Mar 11, 2019 at 10:06:21AM -0700,
 Ted Hardie  wrote 
 a message of 76 lines which said:

> This conflicts with SECDISPATCH, which will have a pretty serious impact on
> who might attend.  Scheduling these things is very hard, obviously. Given
> this topic, you may have to move outside the normal agenda time to get a
> reasonable shot at avoiding conflict.

I avoided conflicts with doh, dprive, dnsop and hrpc but avoiding all
conflicts is close-to-impossible. In the evening, people have
meetings, too.

I admit I'm not sure that Secdispatch is so important here. The
subject of the side meeting is not security-specific.

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

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

[Stephane Bortzmeyer]

[Resent with the correct list of working groups.]

[Sorry for the long list of working groups but the discussion already
started in different places.]

There are been some discussion about DoH (DNS-over-HTTPS, RFC 8484)
deployment and the risk of centralization of Internet services. (See
for instance drafts [this is not an endorsement]
draft-bertola-bcp-doh-clients, draft-reid-doh-operator and
draft-livingood-doh-implementation-risks-issues.)

It was suggested Reference necessary to have a
side meeting in Prague at IETF 104. I propose monday, 1400-1600 in
Tyrolka. The proposal is at
. You
are welcome to agree/disagree/meet in a bar instead.

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

[dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt

[manu tman]

During earlier discussion (post virtual meeting), there were a mixture of
feeling as to where SPKI may be published, here is one proposal bump
(through the rush of time) to publish it in the parent zone.


Manu

———



A new version of I-D,
draft-bretelle-dprive-dot-for-insecure-delegations-01.txt

has been successfully submitted by Emmanuel Bretelle and posted to the

IETF repository.



Name: draft-bretelle-dprive-dot-for-insecure-delegations

Revision: 01

Title: DNS-over-TLS for insecure delegations

Document date: 2019-03-11

Group: Individual Submission

Pages: 7

URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01.txt=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=PTJU2WP56vNJ3OnZN8sxwflDDPzJTP2kbMe7zyinhT8=

Status:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations_=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=SSXjldGIOCQ8_CAJnci1qab0INy6UiD75Fu71efQyW4=

Htmlized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=gwClruoLv-Mu6Sxl37_kCyxOu6Vx5QBV1ppRA0_m5aw=

Htmlized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=MyhcqxSfzLUA2UhuM22MPzog5cLn6OxC_EwQPH7Qe6Y=

Diff:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=aXUkzkp72a1sBvkWpiF9xYstuFWDnXcVoJTRRtLN2tA=



Abstract:

This document describes an alternative mechanism to DANE ([RFC6698])

in order to authenticate a DNS-over-TLS (DoT [RFC7858]) authoritative

server by not making DNSSEC a hard requirement, making DoT server

authentication available for insecure delegations.









Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.



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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-bcp-op-02.txt

[Sara Dickinson]

Hi All, 

This is an update containing mostly minor changes based on feedback so far. We 
do have a slot in DPRIVE to discuss this and the DNS Privacy Considerations bis 
so it would be good to get feedback there on the next steps. 

- Change 'open resolver' for 'public resolver’
- Minor editorial changes
- Remove recommendation to run a separate TLS 1.3 service
- Move TLSA to purely an optimisation in Section 5.2.1
- Update reference on minimal DoH headers. 
- Add reference on user switching provider after service issues in Section 5.1.4
- Add text in Section 5.1.6 on impact on operators. 
- Add text on additional threat to TLS proxy use (Section 5.1.7) 
- Add reference in Section 5.3.1 on example policies.

Sara.

> On 11 Mar 2019, at 16:41, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the DNS PRIVate Exchange WG of the IETF.
> 
>Title   : Recommendations for DNS Privacy Service Operators
>Authors : Sara Dickinson
>  Benno J. Overeinder
>  Roland M. van Rijswijk-Deij
>  Allison Mankin
>   Filename: draft-ietf-dprive-bcp-op-02.txt
>   Pages   : 34
>   Date: 2019-03-11
> 
> Abstract:
>   This document presents operational, policy and security
>   considerations for DNS operators who choose to offer DNS Privacy
>   services.  With these recommendations, the operator can make
>   deliberate decisions regarding which services to provide, and how the
>   decisions and alternatives impact the privacy of users.
> 
>   This document also presents a framework to assist writers of DNS
>   Privacy Policy and Practices Statements (analogous to DNS Security
>   Extensions (DNSSEC) Policies and DNSSEC Practice Statements described
>   in [RFC6841]).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-02
> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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

[dns-privacy] I-D Action: draft-ietf-dprive-bcp-op-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS PRIVate Exchange WG of the IETF.

Title   : Recommendations for DNS Privacy Service Operators
Authors : Sara Dickinson
  Benno J. Overeinder
  Roland M. van Rijswijk-Deij
  Allison Mankin
Filename: draft-ietf-dprive-bcp-op-02.txt
Pages   : 34
Date: 2019-03-11

Abstract:
   This document presents operational, policy and security
   considerations for DNS operators who choose to offer DNS Privacy
   services.  With these recommendations, the operator can make
   deliberate decisions regarding which services to provide, and how the
   decisions and alternatives impact the privacy of users.

   This document also presents a framework to assist writers of DNS
   Privacy Policy and Practices Statements (analogous to DNS Security
   Extensions (DNSSEC) Policies and DNSSEC Practice Statements described
   in [RFC6841]).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-02
https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

[manu tman]

Hi all,

I have captured in a draft the mechanism I used during IETF 103 hackathon
and which is available aan experimental module in knot-resolver[0]. I was
taken short with time before cit-off date, but I hope this will better
explain how it works.

Manu

[0]
https://gitlab.labs.nic.cz/knot/knot-resolver/tree/master/modules/experimental_dot_auth

———



A new version of I-D, draft-bretelle-dprive-dot-spki-in-ns-name-00.txt

has been successfully submitted by Emmanuel Bretelle and posted to the

IETF repository.



Name: draft-bretelle-dprive-dot-spki-in-ns-name

Revision: 00

Title: Encoding DNS-over-TLS (DoT) Subject Public Key Info (SPKI) in Name
Server name

Document date: 2019-03-11

Group: Individual Submission

Pages: 7

URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname-2D00.txt=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=9TmF-DXxE_0nJ6WyhRNoNSiya3N7h_pVwyRn4qIfD7U=

Status:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname_=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=5eZd00_oyy5t1SFYXYCMfv1fSl22SudK5I3pkCozKFs=

Htmlized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname-2D00=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=ZTRurE9sjAPDCKcx8dBXgYPs0dE9LmmJ194vl04cn3Q=

Htmlized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=H0At0r1sQEdFc1snO7kIVALaFf-F1zRRHGPf3aUqkk4=





Abstract:

This document describes a mechanism to exchange the Subject Public

Key Info (SPKI) ([RFC5280] Section 4.1.2.7) fingerprint associated

with a DNS-over-TLS (DoT [RFC7858]) authoritative server by encoding

it as part of its name. The fingerprint can thereafter be used to

validate the certificate received from the DoT server as well as

being able to discover support for DoT on the server.









Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat
___
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

[Konda, Tirumaleswar Reddy]

Please see inline [TR]

From: dns-privacy  On Behalf Of nalini elkins
Sent: Monday, March 11, 2019 11:05 AM
To: Paul Vixie 
Cc: Stephen Farrell ; d...@ietf.org; dn...@ietf.org; 
Christian Huitema ; dns-privacy@ietf.org; Vittorio Bertola 
; Ackermann, Michael 

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.



Paul,

> (yes, i will be part of a major new project to identify and block all DoH 
> services, so
> that behavioural security policies can still work, because you may have
> noticed that the internet has never become MORE secure from new tech,
> but it occasionally becomes LESS secure more slowly because of policy.)

I would be very interested, if you are so inclined, to hear more of what you 
are thinking.   Is this something you can (are willing to) talk about?

[TR] Enterprise networks are already able to block DoH services, it is causing 
the DoH client to fallback to clear-text DNS compromising endpoint security and 
privacy. In draft 
https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-01 we are 
proposing mechanisms to automatically bootstrap endpoints to discover and 
authenticate privacy-enabling DNS servers provided by the Enterprise network.

The user also gets to know the privacy preserving data policy by the DNS server 
and can decide whether to switch to another network or if the user trusts the 
network and privacy policy, the user can enable strict privacy profile with the 
privacy enabling DNS server discovered in the Enterprise network itself instead 
of downgrading to opportunistic privacy profile.

Cheers,
-Tiru

It sounds like a very thought-provoking initiative.

Thanks,
Nalini

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


Christian Huitema wrote on 2019-03-10 21:14:

> There are a bunch of conflicting requirements here, and it would be good
> to tease out the contradictions. Consider the following cases:
>
> 1) I am using my phone, and using application-X.
>
> 2) I am at home, using application-X on my home computer.
>
> 3) I am using Wi-Fi in a hotel, and using application-X.
>
> 4) I am using my work laptop on the enterprise network, and using
> application-X
>
> 5) I am using my work laptop in a hotel, and using application-X
>
> 6) I am using my work laptop on the network of a customer, and using
> application-X.

this distinction is not useful.

there are two cases.

a user or app trusts its network.

or not.

in the first case, you'll use an RDNS service which is in the set
(allowed (preferred)). that is, you'll use the server you desire most
out of the set that your network operator allows you to reach.

in the second case, you'll use a VPN, for all of your traffic, not just
for DNS, because if you hide your DNS but not the connections which
result from such hiding, it will add no measurable privacy.

> Today, plenty of people claim the right to control how I use the DNS: my
> phone carrier, my ISP at home, the company that got the contract to
> manage the hotel's Wi-Fi, the IT manager for my company's laptop, the IT
> manager for the company that I am visiting. Out of those, there is just
> one scenario for which the claim has some legitimacy: if the company
> pays for my laptop and own the laptop, yes of course it has a legitimate
> claim to control how I am using it. Otherwise, I, the user, get to
> decide. If I like the application's setting better than the network's
> default, then of course I expect those settings to stick.

this distinction is also false.

if you are using my network, then it makes no difference which of us
bought you that laptop. you will use the RDNS i allow you to use. RDNS
is part of the control plane, and i use it for both monitoring and
control. sometimes that's so that i can see malware beacon to its C
sometimes that's so that i can institute parental controls.

if you don't like my rules, you should vote with your feet, and not
visit me. because that is the only choice you will have. (yes, i will be
part of a major new project to identify and block all DoH services, so
that behavioural security policies can still work, because you may have
noticed that the internet has never become MORE secure from new tech,
but it occasionally becomes LESS secure more slowly because of policy.)

quoting again the salient passage of RFC 8484's self-damning introduction:

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

let me give you advance notice: "i aim to misbehave."[1] that is, _i am
on-path, and i intend to interfere._ why on earth the IETF decided to
equate dissidents (of whom there are tens of thousands, all of which
need full VPN's not just DoH for actual safety) with bots (of which
there 

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

[Neil Cook]

Hi,

so I think the scenario you describe is worth considering in the draft.

IMO it makes the need for such a draft even more compelling because the idea of 
a browser sending user’s browsing data to any number of (frequently changing) 
third-party resolvers brings up all kinds of issues around privacy, informed 
user consent, not to mention unexpected and unwanted behaviour.

Neil

Sent from my iPhone

> On 11 Mar 2019, at 13:09, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
>> On 11/03/2019 09:25, Neil Cook wrote:
>> What other resolvers would those be? Firefox only uses Cloudflare at
>> the moment. You can manually change that if you know about a
>> different DoH server.
> When I briefly played with FF nightly and DoH, it was
> using both the system resolver and CF. I had to muck
> about some to get it to actually use the CF results
> because of entries in the system resolver cache.
> 
> My point though was that the dichotomy in Vittorio's
> draft is too simple - I'd guess its likely that a
> browser, if doing DoH for real, would end up trying
> various DoH servers as well as the system resolver
> and would make possibly complex choices based on the
> queries, answers and metadata (e.g. speed) seen. And
> those choices could of course change as the browser
> s/w is updated (all that being in addition to the
> kind of user-driven config stuff Vittorio's draft
> mentions).
> 
> Cheers,
> S.
> <0x5AB2FAF17B172BEA.asc>
> ___
> 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] New: draft-bertola-bcp-doh-clients

[Stephen Farrell]

Hiya,

On 11/03/2019 09:25, Neil Cook wrote:
> What other resolvers would those be? Firefox only uses Cloudflare at
> the moment. You can manually change that if you know about a
> different DoH server.
When I briefly played with FF nightly and DoH, it was
using both the system resolver and CF. I had to muck
about some to get it to actually use the CF results
because of entries in the system resolver cache.

My point though was that the dichotomy in Vittorio's
draft is too simple - I'd guess its likely that a
browser, if doing DoH for real, would end up trying
various DoH servers as well as the system resolver
and would make possibly complex choices based on the
queries, answers and metadata (e.g. speed) seen. And
those choices could of course change as the browser
s/w is updated (all that being in addition to the
kind of user-driven config stuff Vittorio's draft
mentions).

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] New: draft-bertola-bcp-doh-clients

[Neil Cook]

> On 10 Mar 2019, at 15:44, Stephen Farrell  wrote:
> 1. I don't think your characterisation of DNS n/w-selection
> vs. application-selection is accurate. IIUC, what's actually
> done by FF is that (if the user has explicitly turned on DoH)
> then FF tries all the resolvers it knows about and figures
> out which to use based on the results and timing it sees.
> That's significantly more complex that the simple dichotomy
> you describe. And I think that difference would ripple
> throughout the document and affect many recommendations.
> 

What other resolvers would those be? Firefox only uses Cloudflare at the 
moment. You can manually change that if you know about a different DoH server.

Neil

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

Re: [dns-privacy] Is there a draft for Knot "Experimental DNS-over-TLS Auto-discovery"

[manu tman]

Right in time before the cut-off date I captured it in a draft:
https://www.ietf.org/id/draft-bretelle-dprive-dot-spki-in-ns-name-00.txt

Manu

On Thu, Dec 27, 2018 at 9:05 AM manu tman  wrote:

>
>
> On Thu, Dec 27, 2018 at 8:28 AM Stephane Bortzmeyer 
> wrote:
>
>> <
>> https://knot-resolver.readthedocs.io/en/stable/modules.html#experimental-dns-over-tls-auto-discovery
>> >
>> was already mentioned in the discussion about encoding keys in
>> names. But is there a draft for this trick? I cannot find one.
>>
>
> There is no draft for it and the only documentation is the one in the
> README, which get rendered in the link you provided.
> I just hacked this up during IETF103 hackathon and just went straight to
> the code, I am more than happy to capture this in a draft if there is
> interest.
>
> Manu
>
>>
>> ___
>> 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] New: draft-bertola-bcp-doh-clients

[Paul Vixie]

Christian Huitema wrote on 2019-03-10 23:05:

On 3/10/2019 10:24 PM, Paul Vixie wrote:


if you are using my network, then it makes no difference which of us
bought you that laptop. you will use the RDNS i allow you to use. RDNS
is part of the control plane, and i use it for both monitoring and
control. sometimes that's so that i can see malware beacon to its C
sometimes that's so that i can institute parental controls.

if you don't like my rules, you should vote with your feet, and not
visit me. because that is the only choice you will have. (yes, i will
be part of a major new project to identify and block all DoH services,
so that behavioural security policies can still work, because you may
have noticed that the internet has never become MORE secure from new
tech, but it occasionally becomes LESS secure more slowly because of
policy.)



"Use a VPN, or use the local defaults".


that is not what i said.


Well, there are plenty of
in-between.


yes, and i gave examples.

see above.


You claim the right to impose your rules, because it is "your network".
Yet you have to define ownership. You are providing network services
under some contractual terms. There are cases where an imperial network
can dictate those terms, but there are also many cases in which the
contractual power of the network is limited  -- thinks like fair access,
network neutrality, etc. Just claiming an empire does not automatically
make you the emperor.


my network, my rules. your provider's network, their rules. they are 
more likely to have to follow their government's laws of commerce and 
privacy than i am likely to have to follow mine. but if the rules your 
network operator can make allow you to do what you want, use that 
network. that's invariant, for all networks, and for all instances of you.


--
P 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/10/2019 10:24 PM, Paul Vixie wrote:

> if you are using my network, then it makes no difference which of us
> bought you that laptop. you will use the RDNS i allow you to use. RDNS
> is part of the control plane, and i use it for both monitoring and
> control. sometimes that's so that i can see malware beacon to its C
> sometimes that's so that i can institute parental controls.
>
> if you don't like my rules, you should vote with your feet, and not
> visit me. because that is the only choice you will have. (yes, i will
> be part of a major new project to identify and block all DoH services,
> so that behavioural security policies can still work, because you may
> have noticed that the internet has never become MORE secure from new
> tech, but it occasionally becomes LESS secure more slowly because of
> policy.) 


"Use a VPN, or use the local defaults". Well, there are plenty of
in-between. For example, I might be using a web proxy, which is sort of
like a VPN but not quite. Or I might be using some web-RTC application,
which uses something else than DNS to identify my peers. DNS is just one
way to locate servers I want to connect to.

You claim the right to impose your rules, because it is "your network".
Yet you have to define ownership. You are providing network services
under some contractual terms. There are cases where an imperial network
can dictate those terms, but there are also many cases in which the
contractual power of the network is limited  -- thinks like fair access,
network neutrality, etc. Just claiming an empire does not automatically
make you the emperor.

-- Christian Huitema


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