Subject: [dns-privacy] Secdir review of draft-ietf-dprive-padding-policy-04

From: Charlie Kaufman <[email-masked]>
Date: Sun, 1 Apr 2018 03:59:42 +0000

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