Eric Rescorla has entered the following ballot position for draft-ietf-dprive-padding-policy-05: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3169 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. ---------------------------------------------------------------------- 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? 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 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. 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? 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. 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. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
