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

Shane Kerr <> Fri, 18 November 2016 06:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D21A012986E for <>; Thu, 17 Nov 2016 22:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lkG72afJ7cfe for <>; Thu, 17 Nov 2016 22:13:46 -0800 (PST)
Received: from ( [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CB0D1296C8 for <>; Thu, 17 Nov 2016 22:13:46 -0800 (PST)
Received: from [240c:f:1:4000:8a63:3b33:66a5:1600] ( by with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1c7cR3-0005XJ-HU; Fri, 18 Nov 2016 06:14:05 +0000
Date: Fri, 18 Nov 2016 14:13:31 +0800
From: Shane Kerr <>
To: Warren Kumari <>
Message-ID: <>
In-Reply-To: <>
References: <>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; boundary="Sig_/0vuOpOB64MHHaMUF7Ab6exN"; protocol="application/pgp-signature"
Archived-At: <>
Cc: "" <>
Subject: Re: [dns-privacy] Call for Adoption: draft-mayrhofer-dprive-padding-profile
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Nov 2016 06:13:48 -0000


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

> This starts a Call for Adoption for draft-mayrhofer-dprive-padding-profile.
> The draft is available here:
> 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

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


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?