Benjamin, thanks for the additional comments. Actually, the idea of specifically describing why the document is Experimental is great. I'll talk to Brian/Chairs whether i should do an RFC editors note, or roll an additional revision. That could also cover your additional suggestions.
best, Alex On Thu, Jul 19, 2018 at 5:07 PM, Benjamin Kaduk <[email protected]> wrote: > 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
