Benjamin, thanks for the review. Comments inline:
On Wed, Jun 20, 2018 at 11:38 PM, Benjamin Kaduk <[email protected]> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dprive-padding-policy-05: No Objection > > ---------------------------------------------------------------------- > 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? The reason for this document to be Experimental was that the recommendation is based on a single empiric study. I would say that if / once more empiric studies are undertaken, we can subsequently create a document with Standards track. Note that such work is eg. proposed in https://mailarchive.ietf.org/arch/msg/pearg/JGuNpoi0IkUPwk6Z08QjXtzTGXA - so we can expect to hear more from the research community in the future. > 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.) This was not considered yet. We do have received another suggestion for a possible padding policy, and my idea was that we could push that to a future revsion of the policy (once we have more empiric findings). I have a question pending to the WG for that other policy to understand what the WG prefers. > 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. Done, thanks for spotting that. Was an editing mishap. > 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. There is currently no way to signal the server's padding policy. We have discussed the idea off-list - However, the result was that even if a server would communicate which policy it followed, a rogue server could still apply a "worse" padding scheme. It all boils down to the trust relationship between client and server, and this is a problem that can hardly be solved "in-band". > [...] 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. This was suggested by Stephen Farrell as part of the WGLC. The respective discussion about that paragraph is here: https://mailarchive.ietf.org/arch/msg/dns-privacy/YYpw8N2V56U-U_vJKwrl1ES28j0 I'm looking at Eric's DISCUSS next, and will look at how to address this. best, Alex _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
