Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
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.
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.
Firstly, thank you for writing this, and also for addressing Joe Clarke's OpsDir notes (and, obviously, thanks to Joe for the review!). I have a clarifying question and some nits: Section 4.2.2: " According to the limited empirical data available, Random Length Padding performs slightly worse than Block Length Padding." Performs slightly worse along what axis? I'm assuming "the server can answer less queries per second", but could also be "uses more RAM", "higher CPU", "explodes randomly", etc. I don't really think that this needs to be addressed, but if you are editing it anyway, and have an easy way to improve it... Oh, Appendix A made me laugh :-) Other than that, some nits: 1: Section 3. General Guidance "EDNS(0) options space: The maximum message length as dictated by protocol limitation limits the space for EDNS(0) options." This flows a little oddly - perhaps "The maximum message length as dictated by the protocol limits the space..." (unless the "limitation limits" entertains you...) 2: Section 4.1: "Note that the recommendation above applies only if DNS transport is encrypted." I suggest "if the DNS transport..."
(I might ballot "yes" on a more mature version of this as standards track or BCP, should one be offered :-) ) Why is this experimental? What is the nature of the experiment? Even if it's just to get more operational experience, it's worth saying that explicitly. §2: There are a number of lower-case versions of normative keywords. Please consider the boilerplate from RFC 8174. §A.2: ' "Fixed Length Padding" MUST NOT be used except for experimental applications.' This entire draft is experimental.
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? 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.) 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. 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. [...] 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.
I'm not sure why this document is experimental. It does not appear to me that it is important to use one common scheme everywhere and therefore just giving a recommendation in an informational doc seems appropriate. I guess with more experience the right next step would be to publish an BCP at some point. The wording on MTU is rather weak in this document, given RFC7830 says: "However, padded DNS messages MUST NOT exceed the number of octets specified in the Requestor's Payload Size field encoded in the RR Class Field (see Sections 6.2.3 and 6.2.4 of [RFC6891])." Maybe be more explicit here. Also the paragraph on MTU and fragmentation appears twice in this doc.
I am bordering on "Yes" for this one.