Last Call Review of draft-ietf-dprive-padding-policy-04

Request Review of draft-ietf-dprive-padding-policy
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-04-04
Requested 2018-03-21
Authors Alexander Mayrhofer
Draft last updated 2018-04-05
Completed reviews Secdir Last Call review of -04 by Charlie Kaufman (diff)
Genart Last Call review of -04 by Meral Shirazipour (diff)
Opsdir Last Call review of -04 by Joe Clarke (diff)
Tsvart Last Call review of -04 by Magnus Westerlund (diff)
Tsvart Telechat review of -05 by Magnus Westerlund (diff)
Assignment Reviewer Charlie Kaufman
State Completed
Review review-ietf-dprive-padding-policy-04-secdir-lc-kaufman-2018-04-05
Reviewed rev. 04 (document currently at 06)
Review result Has Nits
Review completed: 2018-04-05


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: Ready to advance to Experimental if typos are fixed unless someone wants to quibble with the details of the algorithm. The proposed algorithm has an empirical study to back it up.

This document proposes a padding policy for encrypted DNS requests designed to make such requests less susceptible to traffic analysis based on packet length. RFC7830 specifies extension mechanisms to DNS to allow optional padding but makes no recommendations concerning how much padding to use. While no agreement is necessary to assure interoperability between the two ends of a connection, this document gives operational guidance to implementers of reasonable policies to apply.

There is a complex tradeoff between the privacy benefits of large amounts of padding vs. the performance benefits of minimal padding, so there can be no one "optimal" scheme. This document does a good job of enumerating the important considerations for an implementer and the recommended strategy is (in my opinion) a reasonable one for most scenarios. I believe, however, that no padding (listed in Appendix A as a Non-sensible Padding Policy) may be sensible in certain situations where performance is at a premium, and that servers should take their cues from clients and omit padding in a response if the client has omitted it in the request.

I disagree with the "disadvantage" listed in section 4.3 that generating a pseudo-random byte per packet sent could be a "hindrance" on servers. High quality randomness is not needed (e.g., ARC4 would work just fine), and so I would favor a scheme like the one listed in section 4.4. But I don't believe the document should be held up to debate this. If anything, publishing this document would get more people thinking about the problem and perhaps find a reason to revise it later.


Page 4: "pading" -> "padding"
Page 5: "(pseudo) which" -> "(pseudo) random values which"
Page 5: "transction" -> "transaction"
Page 6: "does apply only" -> "applies only"
Page 5: "inffective" -> "ineffective"