Skip to main content

Last Call Review of draft-ietf-dprive-padding-policy-04
review-ietf-dprive-padding-policy-04-secdir-lc-kaufman-2018-04-05-00

Request Review of draft-ietf-dprive-padding-policy
Requested revision 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
I-D 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
Request Last Call review on draft-ietf-dprive-padding-policy by Security Area Directorate Assigned
Reviewed revision 04 (document currently at 06)
Result Has nits
Completed 2018-04-05
review-ietf-dprive-padding-policy-04-secdir-lc-kaufman-2018-04-05-00
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.

Typos:

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"

 --Charlie