Benjamin Kaduk has entered the following ballot position for draft-ietf-dprive-padding-policy-05: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- At risk of triggering suggestions that there is an echo in the room: This document is targetting Experimental status. Is there a way to know when the experiment has ended and/or what the conclusion is? I know this document does not claim to be exhaustive, but I wonder if there was any consideration for a "random multiple fixed block length padding", where a fixed block length is used, but the padded message does not always use the smallest multiple of the block length that will fit the message. That is, sometimes there is an extra block length or three of padding after the "normal" padding to get to the block length. (This strategy is quite closly related to Random Block Length Padding, where the candidate block lengths are multiples of the single "fixed" block length, but I cannot convince myself that the two are completely identical.) Section 4.1 The Block Size will interact with the MTU size. Especially for length values that are a large fraction of the MTU, unless the block length is chosen so that a multiple just fits into the MTU, Block Padding may cause unneccessary fragmentation for UDP based delivery. Also, chosing a block length larger than the MTU of course always forces to always fragment. This paragraph is (modulo two words) a duplication of a previous paragrpah in this section; I think this one (the penultimate paragraph) should be removed. Section 7 No matter how carefully a client selects their Padding policy, this effort can be jeopardized if the server chooses to apply an ineffective Padding policy to the corresponding response packets. Therefore, a client applying Padding may want to choose a DNS server which does apply at least an equally effective Padding policy on responses. Is there any way for the client to determine the behavior of DNS servers in this matter other than trial-and-error? Perhaps some additional text would be helpful. [...] Counter-measures against such other side channels could include injecting artificial "cover traffic" into the stream of DNS messages, or delaying DNS responses by a certain amount of jitter. Such strategies are out of scope of this document. Additionally, there is neither enough theoretic analysis nor experimental data available to recommend any such countermeasures. (This seems very closly aligned with Eric's DISCUSS.) My understanding is that in general, random jitter is not actually very helpful in this regard. So I'm curious to hear a summary of the WG discussions on this strategy. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
