Eric, thanks for your review. Responses inline:
On Tue, Jun 19, 2018 at 12:00 AM, Eric Rescorla <[email protected]> wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-dprive-padding-policy-05: Discuss > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I am marking this DISCUSS because it appears to endorse Random > padding, which is known to be an unsafe practice. > > DETAIL > S 4.2.2. >> 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. >> >> According to the limited empirical data available, Random Length >> Padding performs slightly worse than Block Length Padding. > > Random 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. I will include your text in the description of this policy, and based on your reasoning, change the recommendation into NOT RECOMMENDED. Furthermore, i have recevied multiple comments that aquiring (pseudo) random numbers is not a practical problem anymore, so i will amend that as well. Text proposed for -06: 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: This policy requires a good source of (pseudo) random numbers which can keep up with the required message rates. More importantly, 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 performs slightly worse than Block Length Padding. Due to that, and the risk outlined above, Random Length Padding is NOT RECOMMENDED. Would that address your DISCUSS? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > S 4.1. >> consider that even the zero-length EDNS(0) Padding Option increases >> the length of the packet by 4 octets. >> >> 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). > > Above, you have SHOULD 128 which is very different from 16 bytes. Why > would I ever pad to 16 bytes? The 16 to 128 bytes stem from early discussions around "guts feeling" of what would be sensible. Queries are mostly <100 bytes in length, so padding to 16 byte block lengths does reduce entropy from query lengths quite a bit. We've heard from Android folks that they're concerned about bandwidth usage ("every byte counts"), so based on the recommendation we gave they did not consider padding for the upcoming introduction of TLS-DNS. imho, padding to 16 byte boundaries on the query is still better than not padding at all. I do agree that language like "seems reasonable" is not what we want to see in a standards track document - but that's one of the reasons why the document is Experimental.. Do you have a suggestion how to change that? > S 4.1. >> (see [dkg-padding-ndss] and above for a discussion). >> >> Very large block lengths will have confidentiality properties similar >> to the "Maximal Length Padding" strategy (Section 4.2.1), since >> almost all messages will fit into a single block. In that case, >> reasonable values may be 288 bytes for the query (the maximum size of > > Reasonable values of what? "block size"? You say above that up to 128 > is reasonable which implies that 288 is unreasonable I will change that text to 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. (removing "reasonable"). Does that address your concern? > S 4.1. >> >> Disadvantage: Given an unpadded message and the block size of the >> padding (which is assumed to be public knowledge once a server is >> reachable), the size of a padded message can be predicted. >> Therefore, minimum and maximum length of the unpadded message are >> known. > > Isn't maximum always known, because it has to fit within the message. Right. Thanks for spotting that. I've removed "maximum" from that sentence, changed it to: Therefore, the minimum length of the unpadded message can be infered > S 4.2.1. >> the server. Depending on the negotiated size, this strategy will >> commonly exceed the MTU, and then result in a consistent number of >> fragments reducing delivery probability when datagram based transport >> (such as UDP) is used. >> >> Maximal Length Padding is NOT RECOMMENDED. > > If this is "sensible:, why is it not recommended? Two options: - 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..) > S 4.2.2. >> Advantages: Theoretically, this policy should create a natural >> "distribution" of message sizes. >> >> 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. > S 4.2.3. >> >> Disadvantage: Requires more implementation effort compared to simple >> Block Length Padding >> >> Random Block Length Padding (as other combinations of padding >> strategies) requires further empirical study. > > 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. Tim said he would talk to you about the DISCUSS - please let me know if the above proposals address your DISCUSS and COMMENTS. I would post an updated version once i've heard back. best, Alex _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
