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
- [dns-privacy] I-D Action: draft-ietf-dprive-paddi… internet-drafts
- Re: [dns-privacy] I-D Action: draft-ietf-dprive-p… Alexander Mayrhofer
- Re: [dns-privacy] I-D Action: draft-ietf-dprive-p… Hugo Connery
- Re: [dns-privacy] I-D Action: draft-ietf-dprive-p… Paul Hoffman
- Re: [dns-privacy] I-D Action: draft-ietf-dprive-p… Shane Kerr
- Re: [dns-privacy] I-D Action: draft-ietf-dprive-p… Shane Kerr
- Re: [dns-privacy] I-D Action: draft-ietf-dprive-p… Tony Finch
- Re: [dns-privacy] I-D Action: draft-ietf-dprive-p… Ilari Liusvaara
- Re: [dns-privacy] I-D Action: draft-ietf-dprive-p… Stephane Bortzmeyer
- Re: [dns-privacy] I-D Action: draft-ietf-dprive-p… Stephane Bortzmeyer