Bob, thanks for that comment, i do agree it's misleading. I didn't have time to flesh out that thought, but what i meant is that one strategy could be to pad with a *random* percentage of the remaining space (with a new random percentage on each message, of course). "Fixed length" Random Length padding with eg. an upper limit of 128 octects of padding would still reveal the maximum original message length, while padding with a random percentage of the remaining space would not.
I will update the draft in the next revision accordingly, if there's interest in continuing it. best, Alex On Tue, Nov 1, 2016 at 8:05 PM, Bob Harold <[email protected]> wrote: > > On Tue, Nov 1, 2016 at 7:09 AM, Hugo Connery <[email protected]> wrote: > >> Hi, >> >> The document looks like a great start. >> >> You seem to be using 'strategy' (28 times) and 'profile' (8 times) >> interchangeably. You may wish to prefer one over the other, or >> clearly delineate the difference in meaning. >> >> The list of strategies looks great. Perhaps you could mention >> the "pad the message to the maximum possible message length" >> explicitly as a sub-case of "Block Length Padding". >> >> I am not recommending it, but it has the maximum "confidentiality" >> property (all EDNS messages look identical -- random noise of the same >> size). Thus, it probably deserves an explicit mention, in the same >> way that "no padding" deserves a mention as it has the minimum >> "confidentiality" property. >> >> You spell length as lenght twice in the first paragraph of section 4.5 >> >> Regards, Hugo Connery >> >> On Mon, 2016-10-31 at 22:40 +0100, Alexander Mayrhofer wrote: >> > Hi, >> > >> > I've posted a first rough cut of a "Padding Profile" draft, >> > describing strategies regarding EDNS0 padding size (which we >> > specifically did *not* address in RFC 7830): >> > >> > https://tools.ietf.org/html/draft-mayrhofer-dprive-padding-profile-00 >> > >> > It's more like a "strawman proposal" rather than a polished document >> > in the current version, but i'm more than happy to talk about it in >> > Seoul if we have time. See the full I-D announcement below. >> > >> > best, >> > Alex >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> > >> > >> > Title : Padding Profiles for EDNS(0) >> > Author : Alexander Mayrhofer >> > Filename : draft-mayrhofer-dprive-padding-profile-00.txt >> > Pages : 6 >> > Date : 2016-10-31 >> > >> > Abstract: >> > RFC 7830 specifies the EDNS0 'Padding' option, but does not >> > specify >> > the amount of padding to be used in specific applications. This >> > memo >> > lists the possible options ("Padding Profiles"), discusses the >> > implications of each of these options, and provides implementation >> > guidance. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-mayrhofer-dprive-padding-profi >> > le/ >> >> > Good start. > > 4.4. Random Length Padding > 'Alternatively, pad a certain percentage of "remaining space"?' > -- This, like fixed length padding, is discoverable and thus of no help. > You should specifically recommend against this, in case someone else > thinks of it and does not realize the problem with it. > > -- > Bob Harold > > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
