Charlie, thanks for the detailed review. I will prepare an updated revision once the Last Call is over, so that the IESG can work on an updated revision.
best, Alex On Sun, Apr 1, 2018 at 5:59 AM, Charlie Kaufman <[email protected]> wrote: > 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 > > > > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
