Date: Fri, 18 Nov 2016 14:13:31 +0800
From: Shane Kerr <shane@time-travellers.org>
To: Warren Kumari <warren@kumari.net>
Message-ID: <20161118141331.6f2bbfba@pallas.home.time-travellers.org>
In-Reply-To: <CAHw9_iJ9sz2dWyB=eLW6YjBP2p6bCvamWELpAwvgnONo_ZJ-5g@mail.gmail.com>
References: <CAHw9_iJ9sz2dWyB=eLW6YjBP2p6bCvamWELpAwvgnONo_ZJ-5g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/0vuOpOB64MHHaMUF7Ab6exN"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/jhzehdvr1Chp26lMvi7k9yIpJuE>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Subject: Re: [dns-privacy] Call for Adoption:
 draft-mayrhofer-dprive-padding-profile
Precedence: list

--Sig_/0vuOpOB64MHHaMUF7Ab6exN
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Warren,

At 2016-11-18 13:42:08 +0900
Warren Kumari <warren@kumari.net> wrote:

> This starts a Call for Adoption for draft-mayrhofer-dprive-padding-profil=
e.
>=20
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-mayrhofer-dprive-padding-profile/
>=20
> 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=20
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

--Sig_/0vuOpOB64MHHaMUF7Ab6exN
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYLpwLAAoJEDcyl5z5Z7MGDOsP/3EX7/tjNxUHccG9EICbftom
vzzZ85U2mzHuxY9VMf9a6j0tb5tq0CcIKVKTGjyDhKrrkUY59VgAFoHv0vuHle8L
sNtKZaNy83mOACFLzpbukweowXYXdeMwODdHpBBvGVBIfEdBDnm529FT64NYXZ7u
/Iqbk3MJY9NSGRQQXky0qm5k3nXAWnxUTxb0uahZBrh1gSAYqLw3UPzYZCsdUpA5
l8CcFPUN0f2xuuXwy52sCURIeyH7CfvbC3RcXhcyYw49wyeuh4zFtGGSBbPbJ+u6
vpBaU9isurJzZjImCFJt8344UjqZx9isf9sp/VhliaQ6wysxC3/LtJ2EEtOeLXxz
K1H4oA3gMB5u50bIg6EaaPvvIskLghzHERbz4GLj2dmzN1nL8+grOngEm1jW5eRX
MfFE6WeWtOihoIzghzHAj+EB7THn2i1GKXovVRtBYr/p0ecFxqZVF9ddImh+mPhN
G6R3Cx/ms1jOiUBtMamG7/HNJjiHJ23/IKOZw0rM5r57CNURGqqwLas4p22Xsp4t
dpT1nDT9ZHNlhhlBZUyDdW5yjFuLn81q8P94/PFQHyU/AMX0ZblhONolNwj66rm9
dWkxbVYgY46OZDK75DLGVgvyVmckz2Kc+ckmDLfb9Qkgk6rL6hU70cpRzqXMBwZF
Jw8WKqMBHl40tMYodm3B
=CCJu
-----END PGP SIGNATURE-----

--Sig_/0vuOpOB64MHHaMUF7Ab6exN--