Thanks for https://tools.ietf.org/html/draft-mayrhofer-dprive-padding-profile-00, Alex!
On Tue 2016-11-01 07:09:28 -0400, Hugo Connery wrote: > The list of strategies looks great. Perhaps you could mention > the "pad the message to the maximum possible message length" > explicitly as a sub-case of "Block Length Padding". The draft does mention "the maximum message length as dictated by protocol negotiations" in the "General Guidance" section, but doesn't make it an explicit padding option, or spell out what it is. if you're going to talk about "maximum possible message length" then it becomes necessary to think about that here. Note that the limits are different depending on whether you're using UDP (DTLS) or TCP (TLS), and that the UDP limit depends on the underlying MTU, which servers might not know. the length limit over TCP (TLS) connections is arguably bounded by either the size of the DNS query (16 bits?) or the TLS record boundary (2^14 + 1024, see https://tools.ietf.org/html/rfc5246#page-21). It might be worthwhile to have some discussion about choosing packet size of the (D)TLS cleartext vs. packet size of the TLS ciphertext, since those can be different values. In implementations i've done, it's often much easier to pad the cleartext to a fixed size, and to ensure that the security considerations of https://tools.ietf.org/html/rfc7830#section-6 are followed and that TLS compression is *off*. Bob Harold wrote: > Yes, I hope that the final document specifies all options, including > the bad ones, and provides clear descriptions about the trade-offs > involved. I'm not convinced that documenting all possible patterns, including the bad ones is a great strategy for a standards-track document. I'd much rather this document pick a single strategy, endorse it clearly, and maybe at most include a mention of a few other strategies and why those strategies are not recommended. We want to make things *easier* for implementers, not harder. fwiw, i'm puzzled by the claim that "Random Length Padding [...] is (at first glance) the best strategy". At first glance, i am not necessarily convinced of this -- i found "block length padding" to be the easiest and most understandable strategy when implementing. (I'm also not convinced that a well-seeded, efficient CSPRNG would be any sort of noticable hindrance to a server doing DNS-over-TLS at wirespeed, but it's simply not necessary for block-length padding) One missing proposal is "power of two padding" -- pad up to the nearest power of two, with some minimum. For example, pad up to 128 octets, and then pad to 256 octets, 512 octets, 1024 octets, etc. What would be really great (not as a standards draft, but as a regular study) would be to frame the problem as an adversarial analysis "game", taking samples of real-world DNS traffic, and see what can be inferred From each of these strategies. That might help to quantify the differences between the schemes. --dkg PS you've got RFC 7803 where you mean RFC 7830
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
