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

[Shane Kerr <[e-mail]>]

Warren,

At 2016-11-18 13:42:08 +0900
Warren Kumari <[e-mail]> wrote:

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

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