Subject: [dns-privacy] [[email-masked]: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 18 Jul 2016 22:25:46 +0200

Isn't it time we start working on the resolver-to-auth link?

I know that DPRIVE does not meet in Berlin but, if people who are
there (I'm not) want to discuss it, I'll be interested in feedbacks,
flames and pull requests.

Subject: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt
From: [email-masked]
To: <[email-masked]>
Date: Mon, 18 Jul 2016 13:15:33 -0700
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Next step for DPRIVE: resolver-to-auth link
        Author          : Stephane Bortzmeyer
	Filename        : draft-bortzmeyer-dprive-step-2-00.txt
	Pages           : 6
	Date            : 2016-07-18

Abstract:
   This document examines the possible future work for the DPRIVE (DNS
   privacy) working group, specially in securing the resolver-to-
   authoritative name server link with TLS under DNS.

   It is not intended to be published as a RFC.

   REMOVE BEFORE PUBLICATION: this document should be discussed in the
   IETF DPRIVE group, through its mailing list.  The source of the
   document, as well as a list of open issues, is currently kept at
   Github [1].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bortzmeyer-dprive-step-2/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-bortzmeyer-dprive-step-2-00

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/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Terry Manderson <[email-masked]>
Date: Tue, 19 Jul 2016 07:27:13 +0000

Hi Stephane,

Thanks for starting to enumerate the options/problems related to recursive
resolver to authoritative name server.

As AD, I would very much like to see some operational data points and some
experience from 'the wild' of deployment to better inform a (re)charter
discussion.

That said, I am VERY interested to see individuals start work (as you have
done) and continue to work in parallel with the above goals.

Cheers
Terry

---

From: Shane Kerr <[email-masked]>
Date: Tue, 19 Jul 2016 10:02:13 +0200

Terry,

I think it's weird that we have people who have ideas about needed
standardization work, and we insist that they work outside of a
chartered working group.

I tend to think that recursive-to-authority privacy work should be done
in dprive, but if that working group needs to wait for the standards
they have developed to "bake", then okay. We should work towards a BoF
for a new working group then, right?

Cheers,

--
Shane

At 2016-07-19 07:27:13 +0000

---

From: Terry Manderson <[email-masked]>
Date: Tue, 19 Jul 2016 08:36:08 +0000

Hi Shane,

I also agree that recursive-to-authority privacy should be done in dprive,
and a my desire here is two fold. So yes the developed, but essentially
not yet deployed, standards need to bake. Additionally I feel that
deployment experience as very important input to the next step.

I'm also not insisting folks work outside of the working group. I'll leave
it to the chairs to take (or not) informative presentations at future
meetings on related dprive topics, yet surely priority should be given to
the charter as it stands.

IIRC the consensus at the time for forming dprive as a WG was to first see
a baked stub-recursive solution with experience. I still feel that has
value and feel it's premature to dive into recursive-to-authority in
charter space despite the very good intentions of smart people in this
working group.

Cheers
Terry

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Jul 2016 10:41:15 +0200

On Tue, Jul 19, 2016 at 08:36:08AM +0000,
 Terry Manderson <[email-masked]> wrote 
 a message of 217 lines which said:

> I still feel that has value and feel it's premature to dive into
> recursive-to-authority in charter space despite the very good
> intentions of smart people in this working group.

-1 but, anyway, we don't need a rechartering to post and discuss
drafts. So, remarks about "mine" are welcome. Lets's talk TLS and not
procedures :-)

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Tue, 19 Jul 2016 09:17:37 +0000

Hi,

Summary:

+1

Details:

Way back in the early days of DPRIVE I commented that without
dealing with the recursive to auth link you end up with a privacy
increase that is not quite as good as Tor (but is a big improvement).

Remember the goal: to increase the cost of mass surveillance.

With what we have, people are joining an anonymity set of those
using the recursive resolver.   The watchers know what domains
the community is interested in by watching the "internet" side
of the resolver.  To de-anonymise the set the watcher
needs to watch the network on "both sides" of the recursive resolver
and do timing analysis.

With phase 2 in place, even with the above watching and timing 
analysis all they will know is which auth server a client was interested
in, but not what the query was.

Thus, to really know what is going on the watchers must compromise
the recursive resolver.  And that is a cost increase beyond timing
correlation.

Thanks Stephane for creating "step-2" to describe some of the challenges,
particularly authenticating the authoritative resolver ("authing the auth?").

Regards,  Hugo

---

From: Warren Kumari <[email-masked]>
Date: Tue, 19 Jul 2016 14:02:18 +0200

> the charter as it stands.

Yup, the chairs are perfectly happy for discussions about recursive to
auth to happen on this list, for people to write drafts and discuss
them, for meeting time to discuss these, etc -- however, we will give
priority to stuff which is in our current charter.

We will recharter to do the recursive to auth bit, but feel (along
with our AD) that we are not quite ready for that yet...

So, yes please, discussions and drafts -- and, even more importantly,
evidence of deployment of the current stuff...

W
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

-- 
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: Bob Harold <[email-masked]>
Date: Tue, 19 Jul 2016 11:11:18 -0400

On Mon, Jul 18, 2016 at 4:25 PM, Stephane Bortzmeyer <[email-masked]>
wrote:

> ---------- Forwarded message ----------
> Cc:
I would think that "Key in DNS, authenticated by DNSSEC" would be the
obvious choice.  That might even push DNSSEC adoption.
(Similar to DANE ?  But I don't know much about DANE.)

-- 
Bob Harold

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Jul 2016 17:18:03 +0200

On Tue, Jul 19, 2016 at 11:11:18AM -0400,
 Bob Harold <[email-masked]> wrote 
 a message of 130 lines which said:

> I would think that "Key in DNS, authenticated by DNSSEC" would be
> the obvious choice.

It is mentioned, section 2.2.

For the -00 version, I did not try to order ("obvious" or "best") the
choices. Feedback welcomed.

---

From: Bob Harold <[email-masked]>
Date: Tue, 19 Jul 2016 11:28:12 -0400

> choices. Feedback welcomed.

I was confused by the "bootstrap" issue, or why talk to port 953.  I was
assuming normal unencrypted DNSSEC to get the key, and then encrypt the
query that I wanted to protect.  I can see why some would want to try to
make private getting the key, if possible, but it really complicates
things, so I am not sure it is worth it.  (Just my opinion, of course.)

-- 
Bob Harold

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Jul 2016 17:32:58 +0200

On Tue, Jul 19, 2016 at 11:28:12AM -0400,
 Bob Harold <[email-masked]> wrote 
 a message of 63 lines which said:

> why talk to port 953

That was a typo, it will be fixed in -01

> I was assuming normal unencrypted DNSSEC to get the key,

For privacy, encrypted-but-unauthenticated is certainly better (at
least not worse).

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 19 Jul 2016 12:07:29 -0400

> flames and pull requests.

Why port 953? I thought the registration for the “domain-s” port was
853?

Note that there is at least one DNS server that defaults to listening on
TCP port 953 for its control socket. When I reported the lack of an IANA
port registration to the vendor (ISC-Bugs #41202) I was told there was
no need to register a port for a “private use” protocol.

-- 
Robert Edmonds

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Jul 2016 19:31:07 +0200

On Tue, Jul 19, 2016 at 12:07:29PM -0400,
 Robert Edmonds <[email-masked]> wrote 

> Why port 953? I thought the registration for the “domain-s” port was

It was a bug. It is fixed in the Github repository and the fix will be
published in -01.