Re: [dns-privacy] I-D Action: draft-ietf-dprive-padding-policy-01.txt

Shane Kerr <shane@time-travellers.org> Fri, 07 July 2017 09:58 UTC

Return-Path: <shane@time-travellers.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E1912EC3B for <dns-privacy@ietfa.amsl.com>; Fri, 7 Jul 2017 02:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.434
X-Spam-Level: *
X-Spam-Status: No, score=1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrvsJj0nfai9 for <dns-privacy@ietfa.amsl.com>; Fri, 7 Jul 2017 02:58:29 -0700 (PDT)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49B0129B6A for <dns-privacy@ietf.org>; Fri, 7 Jul 2017 02:58:28 -0700 (PDT)
Received: from [2001:470:78c8:2::9] (helo=earth.zonnestelsel.tk) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1dTQ2f-0001QX-Ks; Fri, 07 Jul 2017 09:59:17 +0000
Date: Fri, 07 Jul 2017 09:58:19 +0000
From: Shane Kerr <shane@time-travellers.org>
To: Hugo Connery <hmco@env.dtu.dk>, dns-privacy@ietf.org
Message-ID: <20170707095819.233ef89c@earth.zonnestelsel.tk>
In-Reply-To: <1499157602.2629.1.camel@env.dtu.dk>
References: <149911712731.22782.2792826496381014188@ietfa.amsl.com> <CAHXf=0pDy9+vp-gfEAfMwb27w8fc8WqSfBL4eC4LZZzLG+XLOw@mail.gmail.com> <1499157602.2629.1.camel@env.dtu.dk>
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_/KMHnMedpd1lKFS+7AA14Ji3"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/EDiEdnL6IH-71X6nTZelEdDlxwQ>
Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-padding-policy-01.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2017 09:58:30 -0000

Hugo,

I'm curious what you mean by this. Do you really mean to propose an
option to pad every query and response message to 65K bytes? I guess I
don't object it for the sake of completion, but it seems a bit crazy.

OTOH, people use Tor for browsing, so maybe someone will actually
want to do this? ;)

Seriously though, on the query side padding beyond a few hundred bytes
is not helpful, because no queries are longer than that. Maybe on the
response side it is indeed more privacy-protecting. 

Cheers,

--
Shane

At 2017-07-04 10:40:02 +0200
Hugo Connery <hmco@env.dtu.dk> wrote:

> Hi Alexander (and list),
> 
> Thanks, Alexander, for your efforts on the document
> (and DKG for the empirical work).
> 
> May I suggest that another strategy is included, that of 
> "always pad to the maximum message size".  This is obviously
> wasteful, and may be recommended against.  However, I believe
> its inclusion is equivalent to the "no padding" and "fixed
> block size pad" options which are listed for completeness whilst
> providing no or very little privacy protection.
> 
> The "always pad to maximum message size" option is actually 
> the maximal privacy setting (when encrypted) but is horribly
> wasteful.
> 
> Perhaps mention it directly after the "no padding option" and
> describe that it provides maximal privacy protection, but is 
> wasteful and more balanced strategies are described below,
> including the recommended strategy.
> 
> Something like this:
> 
> ---
> 
> 4.2 Maximal Length Padding
> 
> In maximal length padding the sender pads every message to the
> maximum allowed size for a message.
> 
> Advantages: Maximal length padding, when combined with encrypted
> transport, provides the highest level of privacy protection.
> 
> Disadvantages: Maximal length padding places a heavy burden on all
> parties, including the client, all intervening network equipment, and
> the server.
> 
> Maximal length padding is not a recommended strategy.
> 
> ---
> 
> Regards,  Hugo Connery
> 
> 
> On Mon, 2017-07-03 at 23:29 +0200, Alexander Mayrhofer wrote:
> > Hi,
> > 
> > i've updated the Padding Policy draft - the main change is the
> > inclusion of an actual recommendation, essentially a blunt copy of
> > Daniel's recommendations from his empirical research work.
> > 
> > I'm looking forward to hearing a discussion around these
> > recommendations - I will subsequently update the draft based on the
> > outcome of those discussions.
> > 
> > best,
> > Alex
> > 
> > 
> > On Mon, Jul 3, 2017 at 11:25 PM, <internet-drafts@ietf.org> wrote:  
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > > This draft is a work item of the DNS PRIVate Exchange of the IETF.
> > > 
> > >         Title           : Padding Policy for EDNS(0)
> > >         Author          : Alexander Mayrhofer
> > >         Filename        : draft-ietf-dprive-padding-policy-01.txt
> > >         Pages           : 7
> > >         Date            : 2017-07-03
> > > 
> > > Abstract:
> > >    RFC 7830 specifies the EDNS0 'Padding' option, but does not
> > > specify
> > >    the length of padding to be used in specific applications.  This
> > > memo
> > >    lists the possible options ("Padding Policies"), discusses the
> > >    implications of each of these options, and provides a
> > > recommended
> > >    option.
> > > 
> > > 
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/
> > > 
> > > There are also htmlized versions available at:
> > > https://tools.ietf.org/html/draft-ietf-dprive-padding-policy-01
> > > https://datatracker.ietf.org/doc/html/draft-ietf-dprive-padding-pol
> > > icy-01
> > > 
> > > A diff from the previous version is available at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-padding-policy-
> > > 01
> > > 
> > > 
> > > 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/
> > > 
> > > _______________________________________________
> > > dns-privacy mailing list
> > > dns-privacy@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dns-privacy  
> > 
> > _______________________________________________
> > dns-privacy mailing list
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy  
> 
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy