On Wed, Jul 18, 2018 at 02:49:47PM +0200, Alexander Mayrhofer wrote: > Benjamin, > > thanks for the review. Comments inline:
Also 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 think we're all excited to hear more from the research community, yes. Do you think it makes sense to add a note in the Introduction that this document is Experimental so that we can get more data from deployments and testing? > > 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. Sure. I don't think you need to hold up this document to add more examples; putting them in a future update seems fine. > > 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". True. I'm ambivalent about whether there's value in adding text about "this choice must be made based on information obtained out of band" or "this requires the client to have some level of trust in the server". > > [...] 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. Hmm, looking at the resolution there, maybe we want to say that an attacker who can observe a large number of requests can still infer information from the resulting distribution, here, as well? But this is almost an in-passing remark that might not merit that level of detail... -Benjamin _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
