On Thu, Feb 26, 2015 at 7:51 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hiya, > > On 26/02/15 12:43, Brian Haberman wrote: > > Are you thinking of looking at patterns of qname values/labels or > > just some number of packets going towards a DNS resolver within a > > certain time frame? > > > > If it is the latter, I think it is out of scope since that type of > > analysis can be done on any type of traffic. If it is the former, > > I agree that such analysis can be prevented with encryption of DNS > > queries going to the resolver. > > I was thinking of the former, so in scope:-) > > However, even considering the latter, if we define some confidentiality > service and if that does include some form(s) of padding then it may > also be possible to mitigate analysis based on message sizes and numbers > of packets. That is jumping ahead a whole bunch of steps though. > For what it is worth, I did include padding in my spec, specifically to defeat traffic analysis based on packet length. Otherwise it would be easy for an intelligence agency to identify people going to a site by putting in a very long DNS name and looking for queries of a specific length. Now I don't want to make that a point of distinction vs the VeriSign proposal as they could add padding. But I think it does show that a lot of thought has to go into the process and that we cannot 'simply reuse' TLS. If we are going to be padding packets in TLS then why not just do what I do and leverage the expensive, complicated part of TLS, the key exchange and replace the easy part, the packet framing? I am not yet done with my architecture paper. But one of the consequences of Snowdonia is that traffic analysis is now part of the threat model and we have to start getting to grips with it. It is not possible to protect against every type of traffic analysis with end to end security. DPRIV is an end to end security enhancement implemented as a session layer replacement so there will be some types of traffic analysis we cannot defend against. There is more than one level of traffic analysis that is relevant: Network Layer: Packet size, IP address, Timing Link Layer: Packet path If you want to have complete traffic analysis protection then you have to work at the Network and Link layers as well as the session layer because that is where the attacks take place. It is possible to add noise at the session layer to provide a degree of security. But we have to be realistic about what we can achieve. We can certainly neuter mass surveillance and most forms of passive attack. We can't be effective against an active attack without a lot of overhead. Rolling up multiple queries into a single query is another technique I use that helps reduce the information leakage (besides improving efficiency). One thing I would like some help with is understanding what the padding quanta should be. I am not sure this needs to go in the spec but we should have some idea. My naive approach is simply to add a random chunk of data then pad every message to a multiple of 64 bytes or the MTU.
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
