Subject: [dns-privacy] Call for Adoption: draft-mayrhofer-dprive-padding-profile

From: Warren Kumari <[email-masked]>
Date: Fri, 18 Nov 2016 13:42:08 +0900

Dear DPRIVE WG,

This starts a Call for Adoption for draft-mayrhofer-dprive-padding-profile.

The draft is available here:
https://datatracker.ietf.org/doc/draft-mayrhofer-dprive-padding-profile/

Please review this draft to see if you think it is suitable for
adoption by DPRIVE,
and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends Fri 02-Dec-2016.

In addition, to satisfy RFC 6702 ("Promoting Compliance with
Intellectual Property Rights (IPR)"):
If you are personally aware of any IPR that applies to
draft-mayrhofer-dprive-padding-profile, has this IPR been disclosed in
compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378
for more details.)

Thanks,
Warren Kumari
(as DPRIVE WG co-chair)
-- 
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: "Paul Hoffman" <[email-masked]>
Date: Fri, 18 Nov 2016 14:23:18 +0900

I support the adoption of this document, knowing that there is still a 
bunch of research that needs to be done before we can specify good 
profiles.

--Paul Hoffman

---

From: Shane Kerr <[email-masked]>
Date: Fri, 18 Nov 2016 14:13:31 +0800

Warren,

At 2016-11-18 13:42:08 +0900

> and comments to the list, clearly stating your view.

I have read this draft and support its adoption by DPRIVE.

> Please also indicate if you are willing to contribute text, review, etc.

I am willing to contribute text, and review, and even etc. if necessary.

--------

Note there was some discussion today in the working group about the
approach that this document takes. The concern is that this seems to be
a survey of possible techniques. Personally I think it makes sense to
have two documents:

1. A review of all possible approaches (the current document), and 
2. Recommendations for implementors (based on pending research and
   analysis).

If we really only want one document, then probably it should start with
recommendations and then include the review of techniques as an
appendix.

--------

I also note two possible issues that I don't think were really
mentioned in the draft:

1. If TCP or some other underlying transport is used which collects DNS
   messages together into a smaller or greater number of packets, it
   may complicate things. At first glance, it seems like this would
   always make an attacker's job harder, but maybe an attacker can do
   things that I might not think of (inducing or otherwise controlling
   delay? forcing retries?). I don't know what to say about this, but
   maybe smarter people on this list have ideas?

2. Timing analysis is still possible even if every message is padded to
   64 kibibyte. Personally I think that this sort of analysis should
   NOT be considered in this draft (or drafts), but rather deferred to
   later work.

--------

Finally, I noticed that someone mentioned that even with a obfuscated
session that the source & destination IP addresses of the servers
involved are still known. This is indeed a problem, but to solve it
means we would need to consider some of the approaches taken by the
various privacy networks like Tor, i2p, GNUnet, or the like.

We are so far from a world where we have any privacy in DNS that I
think we need to focus on the problems that we can actually come close
to solving in the near- or medium-term. But maybe it is worth
considering a research group in the IRTF?

Cheers,

--
Shane

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Nov 2016 13:06:47 +0100

>  bunch of research that needs to be done before we can specify good 

+1

[email-masked]

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 19 Nov 2016 04:07:22 +0900

> This starts a Call for Adoption for draft-mayrhofer-dprive-padding-profile.
 [...]
> Please also indicate if you are willing to contribute text, review, etc.

As i said in the meeting Friday, I support WG adoption of this document.
Implementors need guidance, and implementations should avoid being
fingerprintable.

nitpick: i think it should be called "dprive-padding-policy" instead of
dprive-padding-profile" so that it's harder to confuse with the
authentication profiles document.

> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378

I'm unaware of any IPR that applies to this work.

    --dkg

---

From: "John Levine" <[email-masked]>
Date: 19 Nov 2016 19:48:25 -0000

>bunch of research that needs to be done before we can specify good 

As I said at the microphone, I'd like to adopt it, and then stall it
until we have enough research data to narrow down the list of profiles.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Sun, 27 Nov 2016 08:33:05 -0500

Reminder -- this CfA concludes on Dec 2nd.

W

On Sat, Nov 19, 2016 at 2:48 PM, John Levine <[email-masked]> wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Paul Wouters <[email-masked]>
Date: Sun, 27 Nov 2016 09:12:55 -0500

In favour of adoption 

Sent from my iPhone

> On Nov 27, 2016, at 08:33, Warren Kumari <[email-masked]> wrote:
>

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 28 Nov 2016 11:18:26 +0000

> On 18 Nov 2016, at 06:13, Shane Kerr <[email-masked]> wrote:
> 
> Warren,
> 

+1

+1 

> recommendations and then include the review of techniques as an

I happen to favour this second approach of just one document, evolving the structure of the draft as the recommendations become clearer. 

Sara.

---

From: Bob Harold <[email-masked]>
Date: Mon, 28 Nov 2016 12:59:04 -0500

On Mon, Nov 28, 2016 at 6:18 AM, Sara Dickinson <[email-masked]> wrote:

> I happen to favour this second approach of just one document, evolving the
> structure of the draft as the recommendations become clearer.
>
> Sara.
>

I support and will review.  Prefer one doc.

-- 
Bob Harold