Warren, At 2016-11-18 13:42:08 +0900 Warren Kumari <[email protected]> wrote:
> This starts a Call for Adoption for draft-mayrhofer-dprive-padding-profile. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mayrhofer-dprive-padding-profile/ > > Please review this draft to see if you think it is suitable for > adoption by DPRIVE, > and comments to the list, clearly stating your view. I have read this draft and support its adoption by DPRIVE. > Please also indicate if you are willing to contribute text, review, etc. I am willing to contribute text, and review, and even etc. if necessary. -------- Note there was some discussion today in the working group about the approach that this document takes. The concern is that this seems to be a survey of possible techniques. Personally I think it makes sense to have two documents: 1. A review of all possible approaches (the current document), and 2. Recommendations for implementors (based on pending research and analysis). If we really only want one document, then probably it should start with recommendations and then include the review of techniques as an appendix. -------- I also note two possible issues that I don't think were really mentioned in the draft: 1. If TCP or some other underlying transport is used which collects DNS messages together into a smaller or greater number of packets, it may complicate things. At first glance, it seems like this would always make an attacker's job harder, but maybe an attacker can do things that I might not think of (inducing or otherwise controlling delay? forcing retries?). I don't know what to say about this, but maybe smarter people on this list have ideas? 2. Timing analysis is still possible even if every message is padded to 64 kibibyte. Personally I think that this sort of analysis should NOT be considered in this draft (or drafts), but rather deferred to later work. -------- Finally, I noticed that someone mentioned that even with a obfuscated session that the source & destination IP addresses of the servers involved are still known. This is indeed a problem, but to solve it means we would need to consider some of the approaches taken by the various privacy networks like Tor, i2p, GNUnet, or the like. We are so far from a world where we have any privacy in DNS that I think we need to focus on the problems that we can actually come close to solving in the near- or medium-term. But maybe it is worth considering a research group in the IRTF? Cheers, -- Shane
pgpgE5yzMLn28.pgp
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
