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 <[email protected]> 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, <[email protected]> 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/dns-privacy > > > > _______________________________________________ > > dns-privacy mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy
pgpRZpOwyey3h.pgp
Description: OpenPGP digitale handtekening
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
