On Wed, Jul 18, 2018 at 4:48 PM, Eric Rescorla <[email protected]> wrote: >> Would that address your DISCUSS? > > > Yes, but the pseudo-random text still seems to be there.
Understood - i'm proposing to change the section to the following: 4.2.2. Random Length Padding When using Random Length Padding, a sender pads each message with a random amount of padding. Due to the size of the EDNS(0) Padding Option itself, each message size is hence increased by at least 4 octets. The upper limit for padding is the maximum message size. However, a client or server may choose to impose a lower maximum padding length. Options: Maximum and minimum padding length. Advantages: Theoretically, this policy should create a natural "distribution" of message sizes. Disadvantage: Random Length padding allows an attacker who can observe a large number of requests to infer the length of the original value by observing the distribution of total lengths. According to the limited empirical data available, Random Length Padding exposes slightly more entropy to an attacker than Block Length Padding. Due to that, and the risk outlined above, Random Length Padding is NOT RECOMMENDED. >> >> Options: Block Length - values between 16 and 128 octets for the >> >> queries seem reasonable, responses will require larger block sizes >> >> (see [dkg-padding-ndss] and above for a discussion). [...] > Well, I'm more concerned about "seems reasonable" but you're recommending > something else at the SHOULD level. I don't have proposed text, though. I'll change it to "were discussed before empiric research was performed"? That's a 100% neutral reflection of what happened. >> Such "very large block length" values >> may be 288 bytes for the query (the maximum size of a one-question >> query over TCP, without any EDNS(0) options), and the EDNS(0) buffer >> size of the server for the responses. >> >> Does that address your concern? > > Yes. Should this be "MAY"? I don't think it's a normative MAY. I'll change that to "are", including the max block length for the response size ? >> - I can either change to "Due to resource consumption, Maximal Length >> Padding is NOT RECOMMENDED" >> - or remove "sensible" from the section title. >> >> Personally, i prefer the first option, as the section title in the >> Appendix is "non-Sensible..." (There's a bit of history behind that, >> originally all policies were in one section, and the split was done to >> address a concern that those non-sensible strategies are not seperated >> well enough from the sensible ones..) > > > I guess my question is: "why isn't this in non-sensible" if it's NOT > RECOMMENDED. Hmm - The idea is that the resource consumption concerns might be gone as soon as everyone has eg. 100Gbit/s+ to their mobiles, and DNS traffic doesn't really matter anymore. The privacy concerns might outweight the resource considerations then, and being the strategy that provide perfect privacy, it might very well become feasible. >> >> Disadvantage: This policy requires a good source of (pseudo) >> >> random >> >> numbers which can keep up with the required message rates. >> >> Especially on busy servers, this may be a hindrance. >> > >> > This does not seem like a real issue. By assumption, you are operating >> > over TLS, in which case you have a secret which you can use to drive >> > your PRNG. That should be rather faster than running the crypto for >> > TLS. >> >> As outlined above, i have removed the second sentence. > > > There still seem to be some vestiges. Removed all of it, as outlined above. >> > This does not seem like it is a good strategy. The only advantage >> > seems to be not requiring as much randomness, but as above, this is >> > not a real issue. >> >> The idea was as this requires further empirical study, we would not >> include a recommendation (as in "we don't know enough yet"). The >> reason that strategy is included in the document is that it was >> brought up as a possible option. > > > I think I would just say it's not as good. I'll think about text... >> >> Tim said he would talk to you about the DISCUSS > > That did not happen. However, as noted above, we are good. I think he wanted to talk to you once the proposed solution is on the table. But, based on what you wrote above, i'll prepare a new revision once the responses from the other ADs are in. thanks! Alex _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
