Subject: [dns-privacy] Starting call for adoptions for "the 3 documents"

From: Warren Kumari <[email-masked]>
Date: Tue, 7 Apr 2015 15:33:25 -0400

Hi all,

We are planning on starting a call for adoption on the documents on April 15th.

At the meeting in Dallas we heard that a number of people didn't feel
that they had enough information / knowledge of the documents to make
in informed decision, so we are giving y'all some extra time to read
the documents before kicking off the CfA.

Our plan is to have a *single* call for adoption, listing all 3
documents, and ask people to put in a *clear* indication for each
document if they would like it adopted or not.

We will then decide which we will be adopting -- if we get really
strong support for multiple documents we will adopt multiple...

So, your homework is to read:
Private-DNS - https://datatracker.ietf.org/doc/draft-hallambaker-privatedns/

Confidential DNS -
https://datatracker.ietf.org/doc/draft-wijngaards-dnsop-confidentialdns/

TLS for DNS: Initiation and Performance Considerations -
http://datatracker.ietf.org/doc/draft-hzhwm-dprive-start-tls-for-dns/

before the 15th of this month....

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Aziz Mohaisen <[email-masked]>
Date: Tue, 7 Apr 2015 15:46:38 -0400

During the last month's meeting in Dallas, I was asked by Warren to compile
a list of relevant criteria that we need to consider when evaluating the
potential of each document. The following are starting points, so please
consider them in mind while reading the different documents (and of course
feel free to add whatever you think relevant to enrich the discussion /
guide your opinion):

   1. Can you implement the mechanism?
      - Does it use existing or no existing technology.
      - If you are using new technologies does it allow for unseen
      problems; algorithms, etc.
      - Actual implementation on the client; apps or stub.
      - Does it provide flexibility of choosing providers?
   2. Does it work?
      - How middle boxes will re-act
   3. Is it expensive at the server side?
      - Would it allow for any issues like DDoS?
   4. Does it provide what it claims to provide?
      - Privacy.
   5. Does it require client authentication.
      - What a problem this raises?
      - How that compares to encryption but not authenticated (client) --
      giving the server a proof who they are indirectly by authenticating the
      recursive.
   6. Other issues:
      - Is TCP anycast a problem? How it relates to the various documents?

Thanks,
Aziz

---------
Aziz Mohaisen
www.mohaisen.net

On Tue, Apr 7, 2015 at 3:33 PM, Warren Kumari <[email-masked]> wrote:

> Private-DNS -
> https://datatracker.ietf.org/doc/draft-hallambaker-privatedns/
>
> Confidential DNS -
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Aziz Mohaisen <[email-masked]>
Date: Tue, 7 Apr 2015 16:00:16 -0400

1. Can you implement the mechanism?
      - Does it use existing (standard; or non-existing) technology?
      - If you are using new technologies does it allow for unseen
      problems; algorithms, etc.?
      - Is the actual implementation on the client; apps or stub, and what
      are associated complexities?
      - Does it provide flexibility of choosing providers?
   2. Does it work?
      - How middle boxes will re-act?
   3. Is it expensive at the server side?
      - Would it allow for any issues like DDoS?
   4. Does it provide what it claims to provide?
      - Privacy.
   5. Does it require client authentication?
      - What problems does this raise? e.g., with respect to privacy,
      reliability, etc.
      - How does that compare to encryption but without (client)
      authentication?
   6. Other issues:
      - Is TCP anycast a problem? How it relates to the various documents?

Thanks,
Aziz

---------
Aziz Mohaisen
www.mohaisen.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Apr 2015 10:36:17 -0400

> strong support for multiple documents we will adopt multiple...

I think that the more important question is how we partition the
problem up and how we address each part. Documents are only a bunch of
text and it is doubtful much of what is there now will survive if
anything.

As I see it, there are two sub-problems:

1) How does a client discover and establish a binding to a DPRIV service?
2) What transport/sessions(s) are supported for queries?

Before answering either, I think it is pretty clear that at some point
in the future, SPUD will be the logical choice for transport/session.
It is also clear that we should not build research on research.

So the way forward as I see it should be that our answer to (1) should
support some mechanism for advertising alternative transports so we
can use TLS for now and make use of SPUD if  and when it matures.

The hard part of the problem is all in problem 1. I designed,
implemented and wrote the draft for the transport/session part in a
day. It isn't a difficult problem (if you are only solving DNS, SPUD
is a lot harder). The hard question is how to discover and establish a
binding to the DNS service before you have DNS.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 13 Apr 2015 10:57:05 -0400

[ Top post ]

What do other think here -- do we want to decide on the discovery and
binding problem first, or do we think that we should choose a document
and start working on that (and possibly add in discovery / binding
later)?

<no-hats>
I'd personally like to start working on a document - i think it helps
focus us in something concrete, and will move the discussion from an
abstract type thing to actually getting work done...
</no-hats>

W

---

From: "Mankin, Allison" <[email-masked]>
Date: Mon, 13 Apr 2015 15:46:20 +0000

Warren,

I think that any/all of the documents can add issues and address the two points that Phillip raised, so I agree with your
no-hats statement and I support the starting of a call for adoption, rather than discussing the points (and others) in vacuo. 

FYI - we are about to update the dns-over-tls draft with new material, some of which pertains to Phillip’s issue 1 in particular;
there were verbal comments in Dallas about that issue from several parties.

Allison

> On Apr 13, 2015, at 10:57 AM, Warren Kumari <[email-masked]> wrote:
> 
> [ Top post ]
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 13 Apr 2015 16:13:18 -0400

> can use TLS for now and make use of SPUD if  and when it matures.

I'm not convinced that SPUD is the long-term way forward, fwiw.  But
there was enough discord between the different proposals within DPRIVE
that "use TLS for now" seems like it would be a great consensus to come
to.  I hope we reach it.

I'd like to make sure we have a clear sense of how to do this securely

> binding to the DNS service before you have DNS.

I don't think this is quite as hard as you're making it out to be.
We're going from:

 * for each resolver, get:
    - an IP address

to:

 * for each resolver, get:
    - an IP address
    - a privacy-preserving transport mechanism
    - a trust anchor

Current discovery mechanisms are:

 * Manual configuration
 * DHCP

i think most people consider DHCP configuration to be at best minimally
useful for DPRIVE -- it leaves you vulnerable at network connection
time, but then protects you against subsequent attacks.  *shrug*

Perhaps DHCP could be seen as a mechanism to propose available choices
for manual configuration?

At any rate, i think we shouldn't block transport mechanism work on
discovery mechanism work.

          --dkg

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Apr 2015 16:21:25 -0400 (EDT)

> time, but then protects you against subsequent attacks.  *shrug*

If you have an attacker on the last mile, there is nothing you can do.
Passive only protection against the last mile is a wasted effort. On
the last mile, there are only active attackers.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Apr 2015 22:20:52 +0100

Hi Paul,

I'm not sure if your point was meant to relate only to DHCP
setting the DNS server IP, but if not then I have a question...

> the last mile, there are only active attackers.

Do you have evidence of the absence of passive attackers and if
so with what definition of last mile?

Noting that an active attack is possible does not IMO mean that
defence against a passive attack is worthless. That is a case
that would need to be made IMO. And the counter argument is that
the probability of an active attack may differ significantly from
the probability of a passive attack.

Basically, I think you're overstating things in the quoted text.

S.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Apr 2015 17:31:28 -0400 (EDT)

> setting the DNS server IP, but if not then I have a question...

Nope.

> so with what definition of last mile?

Googling for "wifi mitm software" comes up with dozens of scripts that
are trivially run. The barrier to entrance is zero.

> defence against a passive attack is worthless.

Agreed, provided there is an actual difficulty difference between the
two. For wifi at starbucks, there is really no reason for an attacker
to stop at being a passive attacker.

> the probability of a passive attack.

That is surely true for passive attackers upstream and further in the
core. but I do not think that applies to the last mile. The only reason
for not doing an active attack is because it is not needed, not because
there is any technical difficulty in performing an attack using a
downloaded program with zero computer knowledge.

> Basically, I think you're overstating things in the quoted text.

That is quite possible, I have no numbers.

I'd like the WG to focus on building an encryption method to a remote
DNS server that can be authenticated regardless of the last mile. Then
adopt a "better than nothing variant" of that for the last mile. And not
build something from scratch just for the last mile. I strongly believe
that's not worth it.

Paul

---

From: Daniel Migault <[email-masked]>
Date: Mon, 13 Apr 2015 17:36:10 -0400

Hi,

Just for information, what are the technical reasons IPsec has not been
considered at all for providing DNS privacy.

The use of IPsec could re-use existing extensions like NAT traversal,
compatibility with UDP/TCP, resilience to change of IP addresses... and
this without creating new extensions.

Would it worth being documented ?

BR,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Apr 2015 17:44:35 -0400 (EDT)

On Mon, 13 Apr 2015, Daniel Migault wrote:

> Just for information, what are the technical reasons IPsec has not been considered at all for providing DNS privacy.

People can already use an IPsec VPN and a remote DNS server without
anything new from IETF?

I think additionally, IPsec has a higher barrier to entrance because it
needs more priviledges to build a system host tunnel as compared to an
application encryption tunnel like (D)TLS. Also, IPsec does not yet
allow the client to remain anonymous - although we're almost done that
part with draft-ietf-ipsecme-authnull. And you _can_ already use that
if you support IKE authnull to 193.110.157.123  (although it does not
yet support one-sided auth where the IKE client verifies the IKE server)

Having an IPsec protected DNS connection is a very good and solid
solution. But an individual application cannot decide to use such
encrypted DNS. Using an application based (D)TLS would allow an
application to make encrypted DNS possible without requiring the system
core OS to have some support for that.

> The use of IPsec could re-use existing extensions like NAT traversal, compatibility with UDP/TCP, resilience to change of IP
> addresses... and this without creating new extensions.

But you get those as well using (D)TLS ?

Paul

---

From: Warren Kumari <[email-masked]>
Date: Mon, 13 Apr 2015 17:54:08 -0400

> time, but then protects you against subsequent attacks.  *shrug*

<no hats>
Well, all depends on what your threat model is / who you are protecting against.

My home router also provides wireless, protected with WPA and client isolation.
My Internet access is a 4.5 mile WiFi link (authenticated using PPPoE)
to an ISP that I don't really trust.
Their DNS performance is horrendous (possibly because last time I
checked they were running BIND 9.3.2 as an open recursive, and were
often used in reflection attacks), and so I've configured my CPE to
hand out 8.8.8.8, 8.8.4.4 via DHCP.

I'm not really concerned about someone who is able to hop on my home
wifi providing fake DNS servers over DHCP - I *am* concerned about all
of my DNS packets flying through the air unencrypted from my house to
the ISP, and on the 12 hops from my ISP to 8.8.8.8.

I have another location where I connect to Comcast (who I trust way
more than my regular ISP!).
Comcast has provided the CPE in this case and it hands out Comcast DNS
servers via DHCP.  I'd be happier accepting DPRIVE info via DHCP from
my CPE than simply shipping queries across buried cables in the clear.

What I'd kind of assumed was that machines would be configured with a
specific DPRIVE server to talk to (and not blindly trust DHCP), but I
think that in many / most cases trusting DHCP is better than
nothing...

W

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Apr 2015 19:42:46 -0400 (EDT)

On Tue, 14 Apr 2015, Stephen Farrell wrote:

> I wonder if the last mile concept is what we really want.

Hmm, you are right. I guess we use "last mile" as a short hand.
The two situations really are:

1) a remote DNS server for which we have a public key and can
authenticate and encrypt with.

2) a local (local-ish or sometimes remote) DNS server, for which we have
no identity information so we can encrypt but not authenticate.

Usually 2) is the "last mile" and 1) is usually not the "last mile"

I think we should strive to have many of 1) available for people all
over the net. And that 2) should only be used to confirm (via DNSSEC)
a transport to reach 1)

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 14 Apr 2015 15:15:49 +0200

On Mon, Apr 13, 2015 at 05:36:10PM -0400,
 Daniel Migault <[email-masked]> wrote 
 a message of 149 lines which said:

> Just for information, what are the technical reasons IPsec has not
> been considered at all for providing DNS privacy.

It _was_ considered during the meeting in London:

http://www.ietf.org/proceedings/89/dnse.html
http://www.ietf.org/proceedings/89/minutes/minutes-89-dnse

(the talk by Eric Rescorla, "IPsec probably isn't going to
work here")

---

From: 神明達哉 <[email-masked]>
Date: Tue, 14 Apr 2015 11:08:08 -0700

At Mon, 13 Apr 2015 10:57:05 -0400,

> abstract type thing to actually getting work done...

I support this approach.  Given that we are already behind the
schedule and there will be quite likely more delays (as usual in the
IETF in general), I think it's more practical and productive to start
working on concrete proposals with keeping in mind
abstract/architectural points than spending even more time on these
issues first.

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Tue, 14 Apr 2015 17:15:58 -0400

On Tue, Apr 14, 2015 at 2:08 PM, 神明達哉 <[email-masked]> wrote:
> I support this approach.

Excellent. I have seen more support for this than for the
"partitioning the problem up" proposal, and so we will be starting
CfAs tomorrow.

Please remember to read the documents!

W

>  Given that we are already behind the