Subject: Re: [dns-privacy] Opsdir last call review of draft-ietf-dprive-padding-policy-04

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 12 Apr 2018 10:11:34 +0200

All,

the OPSDIR review from Joe Clarke suggests a re-ordering of the
document flow in order to better appeal to folks with operational
background. I'm considering changing the structure of the document,
but i would appreciate yes/no indications from the group before i
proceed. This would not induce any protocol-level change, but would
still be a change that i consider significant enough for the WG to
discuss.

My suggestion to change the structure would be as follows:

CURRENT:

   1.  Introduction  . . . . . . . . . .
   2.  Terminology . . . . . . . . . .
   3.  General Guidance  . . . . .
   4.  Padding Strategies  . . . . . .
     4.1.  Block Length Padding  . . . . . . . .
     4.2.  Maximal Length Padding ('The Full Monty') . . .
     4.3.  Random Length Padding . . . . . . . . . . . . .
     4.4.  Random Block Length Padding . . . . . . . .
   5.  Recommended Strategy  . . . . . . . . . . . . . . .
   6.  Acknowledgements  . . . . . . . . . . . . . . .
   7.  IANA Considerations . . . . . . . . . . .
   8. Security Considerations . . . . . . . . .

NEW:

   1.  Introduction  . . . . . . . . . .
   2.  Terminology . . . . . . . . . .
   3.  General Guidance  . . . . .

   4.  Padding Strategies  . . . . . .
     4.1.  Recommended Strategy (Block Length Padding)
     4.2.  Other Potential Strategies
     4.2.1.  Maximal Length Padding ..............
     4.2.2.  Random Length Padding . . . . . . . . . . . . .
     4.2.3.  Random Block Length Padding . . . . . . . .
   5.  Acknowledgements  . . . . . . . . . . . . . . .
   6.  IANA Considerations . . . . . . . . . . .
   7. Security Considerations . . . . . . . . .

I think it totally depends on the viewpoint (operational vs.
"research-oriented"). Please share your preferred option - keep with
CURRENT or restructure for NEW.

thanks,
Alex

On Mon, Mar 26, 2018 at 6:45 PM, Joe Clarke <[email-masked]> wrote:
> Reviewer: Joe Clarke
> Review result: Has Nits
>
> I have been asked to review this document on behalf of the ops directorate.
> This document is intended for experimental status, and describes a number of
> strategies to take when performing EDNS(0) padding.  It recommends one
> (experimental) option to use based on empirical data.  Overall, I think this
> document is close to be ready.  In general, coming at it from an operator
> standpoint, I thought the layout was a bit odd.  The recommended option is
> spelled out first, but then the document goes into sub-optimal approaches
> before it actually describes the full recommended solution (both from a query
> and response stance).  It might flow better to discuss the recommended approach
> in detail while leaving all of the sub-optimal approaches for appendices.  At
> the very least, the Maximal Length Padding approach feels somewhat non-sensible
> and should be pushed to the appendix.
>
> Nit-wise, I found the following:
>
> Section 3:
>
> s/signifcantly/significantly/
>
> s/octects/octets/
>
> ===
>
> Section 4.1
>
> You refer to Maximum Length Padding here, but Section 4.2 calls it "Maximal
> Length Padding".
>
> ===
>
> Section 4.2
>
> Is referencing "The Full Monty" needed here?
>
> ===
>
> Section 4.3
>
> You expand (pseudo) to (pseudo) random number in Section 4.1.  I think the same
> should be done here for clarity.
>
> ===
>
> Section 4.4
>
> s/transction/transaction/
>
> ===
>
> Section 5
>
> When you talk about a multiple of 468 bytes used for response padding, I think
> you should include a "see below".
>
> ===
>
> Section 5
>
> s/octects/octets/
>
> ===
>
> Section 5
>
> Where you have "Note that the recommendation above does apply only..." I think
> it reads better to say, "Note that the recommendation above applies only..."
>
> ===
>
> Section 8
>
> s/inffective/ineffective/
>

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 12 Apr 2018 10:11:34 +0200

All,

CURRENT:

NEW:

thanks,
Alex

---

From: Shane Kerr <[email-masked]>
Date: Thu, 12 Apr 2018 08:50:00 +0000

Alex,

I think that the new way probably makes slightly more sense.

So I prefer the NEW order.

Cheers,

--
Shane

Alexander Mayrhofer:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 12 Apr 2018 10:43:18 +0100

> On 12 Apr 2018, at 09:50, Shane Kerr <[email-masked]> wrote:
> 
> Alex,
> 

+1 for the NEW order although I might suggest calling Section 4.2 something like “Other Strategies Evaluated"

Sara.

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 12 Apr 2018 11:23:27 -0400

> CURRENT or restructure for NEW.

I prefer the NEW option of putting the recommendation before the
discussion of other possibilities.

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 12 Apr 2018 11:23:27 -0400

---

From: Hugo Connery <[email-masked]>
Date: Thu, 12 Apr 2018 18:41:04 +0200

+1 again.  

However, we also need  to re-order the "Other recommended 
strategies" to be next best, next best, worst
(as much as that is possible).  

Thus, the Maximal Length padding should come *last*, but as already
acknowledged, it does need to be there.  It is the best choice for the
privacy conscious, but the worst choice for the network and DNS
operators.

Regards,  Hugo (who originally pushed for the inclusion of Maximal)

On Thu, 2018-04-12 at 10:43 +0100, Sara Dickinson wrote:
> +1 for the NEW order although I might suggest calling Section 4.2
> something like “Other Strategies Evaluated"
> 
> Sara. 
> 
[snip some].
> > >     4.2.3.  Random Block Length Padding . . . . . . . .
Re-order these three ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[snip more].

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 12 Apr 2018 20:18:14 -0400

> CURRENT or restructure for NEW.

I prefer NEW (i like having the recommendation up front) but would not
be sad if we stuck with CURRENT either.

   --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 12 Apr 2018 20:18:14 -0400

--dkg

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 13 Apr 2018 12:11:36 +0200

Thanks everyone for their feedback. I've now changed the document flow
according to the NEW structure outlined above, and will publish a -05
shortly.

best,
Alex

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 13 Apr 2018 12:11:36 +0200

best,
Alex