Re: [secdir] Secdir review of draft-ietf-dprive-padding-policy-04

[Alexander Mayrhofer <[e-mail]>]

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
<[e-mail]> 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
>
>
>
>