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

[Sara Dickinson <[e-mail]>]

> 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.