Stephane, Stephen, i've just posted -04 of the draft, addressing your WGLC comments as follows:
On Mon, Jan 29, 2018 at 4:58 PM, Stephane Bortzmeyer <[email protected]> wrote: > On Mon, Jan 22, 2018 at 02:00:16PM +0000, > Stephen Farrell <[email protected]> wrote > a message of 241 lines which said: > >> - Is there any (good) literature on related mechanisms that one >> might use to further increase the difficulties of traffic analysis >> based on DNS traffic? I'm thinking about synthetic cover traffic or >> of adding jitter to the timing of requests, but there could be other >> things one might do. Even if we aren't in a position to provide >> experimental recommendations about such things, (I'd be happy if we >> were), it'd be good to at least add a mention and some references if >> we could. While such work could be done later and in a separate >> specification, it is pretty closely related to this so would also >> fit nicely in here if we had good text to add. (I don't have text to >> offer, sorry.) > > I suggest an appendix "Besides padding" with: > > It is possible that there are other mechanisms that one might use to > further increase the difficulties of DNS traffic analysis. For > instance, gratuitous queries and/or answers could be added to cover > the real traffic. Or jitter could be added, with a random delay before > replying. We currently don't have enough theoretical analysis or > experimental data to recommend one of these mechanisms. I've extended the relevant paragraph in the security considerations section to say: "Note that even with encryption and padding, it might be trivial to identify that the observed traffic is DNS. Also, padding does not prevent information leak via other side channels (particularly timing information and number of query/response pairs). 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." >> - There's no way to know (for sure) which padding scheme a peer is >> using I think? > > Local decision, indeed. > >> If so, would there be any benefit in making that possible? I think >> the answer is that's there's not enough to gain by doing so. > > And it's complicated: there are several policies, each with several > parameters. It would require the standardization of a mini-language, > and of an IANA registry of padding policies. I agree with Stephane - it would be pretty complicated, and unless there's a clear indication there's an advantage knowing about the policy of the other side, there's no real use (eg. if two policies interacted in a particularly favorable way..) Also, this would rather require updating RFC 7830 to allow for signalling, or introducing even another EDNS option .... I'd rather not follow that rathole for now :) best, Alex _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
