Re: [dns-privacy] Version -02 of draft-ietf-padding-policy

[Alexander Mayrhofer <[e-mail]>]

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 <[e-mail]> wrote:
>
> On 28 Sep 2017, at 15:23, Alexander Mayrhofer <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>