Hello, as mentioned during yesterday's DPRIVE side meeting, i'm planning to roll another revision of the padding-policy draft, in the hope that we can WGLC the draft after that revision. I've received comments from Sara (see above in this thread, much appreciated!), plus a few small comments during yesterday's meeting.
If you have any additional comments, please speak up now (rather than during the WGLC) so that i include your feedback in the next revision. Thanks! best, Alex On Sat, Oct 7, 2017 at 1:00 AM, Sara Dickinson <[email protected]> wrote: > > On 28 Sep 2017, at 15:23, Alexander Mayrhofer <[email protected]> > wrote: > > Hello everyone, > > > I’ve just posted version -02 of the Padding Policy draft. This version > consideres comments from the Prague WG sesson and subsequent mailing list > discussions. Specifically, the major changes are: > > - Changed Document status to „Experimental“ > - Added „Maximum Length“ padding strategy > - Reworded „Block Length“ strategy > - Added text with RFC2119 language to each strategy > - Provided justification for the recommended strategy. > > Please review and comment. I’m happy to talk about it in Singapore, and i > think we should be pretty close to WGLC‘ing it out of our eyes after that :) > > > > Hi Alex, > > Thanks for this update - I think this is taking shape now. I have a few > comments and a bunch of nits: > > Comments: > - I wonder if it is worth a comment about the fact padding doesn’t obfuscate > that the packet is DNS traffic? The draft clearly talks only about hampering > size-based correlation attacks but it just struck me that hiding the fact > the traffic is DNS (for example, if port 443 were used) is a non-goal for > this document. > > - I suspect the data used in the analysis didn’t include many (if any) > DNSSEC validating clients… If they become more common then I would expect > the response size padding to alter. Perhaps add a comment to this effect in > section 5? > > - Section 4.5: “Maximum (and eventually minimum) padding length.” Why > ‘eventually’ minimum? Do you mean implicitly? > > - Section 4.6: s/Number of size of the set of Block Lengths/Number of and > the values for the set of Block Lengths/ ? > > - Section 5: List item (2). Would it be useful to be more explicit here and > say something like > “If a Server receives a query that includes the EDNS(0) padding option, it > MUST pad the corresponding response [RFC7830] and SHOULD pad the > response to a multiple of 468 octects." > > Nits > - Introduction: Reference to RFC7830 at the start of the first sentance is > repeated. > - I see EDNS, EDNS0 and EDNS(0) used in different places in the document. > Perhaps use EDNS(0) throughout? > - Section 4: Full stop missing at the end of the first sentence. > - Sections 4.2 and 4.5: Full stop missing at the end of the ‘Advantages’ > statement. > - Section 4.2: s/of padding easily discoverable/of padding is easily > discoverable/ > - Section 4.2 "padding hence must be assumed” Remove hence? > - Section 4.5: s/a good source of (pseudo) keeping/a good source of (pseudo) > random numbers which can keep up/ > - Section 4.6: s/a few block lenght’es/a few block length values/ > - Section 4.6: s/selection of block lenght/selection of block length/ > - Section 4.6: last sentence s/require further/requires further/ > - Section 8: s/the chose policy/the chosen policy/ > - Section 8: s/A clients carefully chosen Padding policy/A clients' > carefully chosen Padding policy/ > - Section 8: s/server does apply an inffective (or no)/ server chooses to > apply an ineffective (or no)/ > - Section 8: s/want to chose a DNS server/want to choose a DNS server/ > > Sara. > > _______________________________________________ > 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
