On Wednesday, November 25, 2015 10:16 AM, Daniel Kahn Gillmor wrote: > ... > tl;dr: It's not this simple, and we should not try to use this draft to > specify padding policy.
+1. The draft is short and simple. It specifies the option code, the option syntax, the expected value, and the expected processing by receivers. We should leave it at that and get it published. The precise ways to use padding is indeed a profound rabbit hole. We can debate whether DNS level padding is preferable to TLS padding per RFC 7685. We can debate whether padding should be all zeroes, or random, or something clever. We can debate whether the length of padding should be to the max MTU size, to some logarithmic sliding scale, or to some random value. All of these have been proposed, all of these make at least some sense, and many of these will probably end up implemented. One thing is certain, we will not be able to get a strong consensus on any particular solution, and we probably will not be able to make a complete inventory in the option specifying draft. Nor should we. The draft as is will not block the clever things that implementers can come up with in the future. It achieves its objectives: get the option code reserved, and make sure that the option can be used without creating interop issues. We should be happy with that. -- Christian Huitema _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
