Re: [dns-privacy] A pool is not an onion
On Sat, Oct 25, 2014 at 07:35:11PM -0700, Watson Ladd watsonbl...@gmail.com wrote a message of 54 lines which said: Before DPRIV: anyone who owns the DNS box at an ISP can see all dns-queries go through, and know who made them. After: exactly the same. You seem to consider that DPRIVE = encryption of the stub-to-resolver link and nothing else. But DPRIVE may work on other things that will improve the situation such as recommending local (local = on the user's machine or network) resolvers before, or instead, IAP's resolvers. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A pool is not an onion
On Oct 25, 2014, at 7:35 PM, Watson Ladd watsonbl...@gmail.com wrote: Before DPRIV: anyone who owns the DNS box at an ISP can see all dns-queries go through, and know who made them. After: exactly the same. Why? Because we were lazy, and solved the easy problems instead of the worthwhile problems. Or: because we don't have the same threat model that you are proposing, and we want something deployable. Nothing in the current proposals prevents you from proposing your still-academic PIR proposals for a longer-term solution that applies to people who agree with your threat model. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A pool is not an onion
On Oct 26, 2014 8:09 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Oct 25, 2014, at 7:35 PM, Watson Ladd watsonbl...@gmail.com wrote: Before DPRIV: anyone who owns the DNS box at an ISP can see all dns-queries go through, and know who made them. After: exactly the same. Why? Because we were lazy, and solved the easy problems instead of the worthwhile problems. Or: because we don't have the same threat model that you are proposing, and we want something deployable. Nothing in the current proposals prevents you from proposing your still-academic PIR proposals for a longer-term solution that applies to people who agree with your threat model. The choice of threat model is really a question about what attackers can do. We know that untrusted network traffic can be read. (A truth DNS working groups have never accepted) The only solutions that come close to handling this are Qname minimization plus DNScurve. Why don't the people who have proposals explain what they can deal with and what they can't so we can judge? Furthermore, some PIR protocols amount to hashing together some records on the server. While not perfect, they can be deployed and do make things harder for attackers. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A pool is not an onion
On Sun, Oct 26, 2014 at 10:59 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Sat, Oct 25, 2014 at 07:35:11PM -0700, Watson Ladd watsonbl...@gmail.com wrote a message of 54 lines which said: Before DPRIV: anyone who owns the DNS box at an ISP can see all dns-queries go through, and know who made them. After: exactly the same. You seem to consider that DPRIVE = encryption of the stub-to-resolver link and nothing else. But DPRIVE may work on other things that will improve the situation such as recommending local (local = on the user's machine or network) resolvers before, or instead, IAP's resolvers. One of the main reasons we get little done in security is that people tend to derail discussions of the possible with demands for the perfect. The other main reason is reductionism, demanding security solutions that only fit in one box. Traditionally the IETF demanded end-to-end security on a take it or leave it basis. And so today 99.99% of email is not encrypted with PGP or S/MIME. But something like 50% is secured using STARTTLS. The reason I originally designed OmniBroker and PRIVATE-DNS was that I have spent over ten years trying to get browser providers to implement DNSSEC so we could do security policy and I know the constraints they raise. Their #1 concern is to minimize latency. In security concerns, preventing state censorship is probably a higher concern than privacy. But only Mozilla is likely to give a candid answer on that. So we have a hierarchy of security concerns. 0) [Solved] Authenticity of authoritative data 1) Authenticity, Integrity and Confidentiality of DNS stub-resolver traffic 2) Confidentiality of DNS resolver-authoritative traffic 3) Disclosure by the resolver We can address (1) very simply and cheaply and do so in a fashion that is compatible with (3). What we can't do is to provide (3) without severe impact on latency. And if you don't solve the latency problem then you end up with the Harvard TOR-DOX issue. Use of TOR is very thin so any use of TOR becomes suspect. So when someone called in a bomb threat to avoid taking a final that day, all the Harvard police needed to do was to look at the campus network logs, find out who was using TOR when the threat was called in and call them both in for interrogation. We can address 1 and 2 with encryption. But solving 3 properly requires steganography. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A pool is not an onion
On Sun, Oct 26, 2014 at 11:09 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Oct 25, 2014, at 7:35 PM, Watson Ladd watsonbl...@gmail.com wrote: Before DPRIV: anyone who owns the DNS box at an ISP can see all dns-queries go through, and know who made them. After: exactly the same. Why? Because we were lazy, and solved the easy problems instead of the worthwhile problems. Or: because we don't have the same threat model that you are proposing, and we want something deployable. Nothing in the current proposals prevents you from proposing your still-academic PIR proposals for a longer-term solution that applies to people who agree with your threat model. Well some of the proposals are better suited to dropping in an alternative privacy protecting transport layer such as TOR than others. This is a use case I have considered in depth for an interested party. SXS-Connect allows a service to specify the transport. While UDP and TCP are the defined values, someone could use TOR. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A pool is not an onion
On Sat, Oct 25, 2014 at 10:35 PM, Watson Ladd watsonbl...@gmail.com wrote: On Sat, Oct 25, 2014 at 7:04 PM, Phillip Hallam-Baker i...@hallambaker.com wrote: I think that we have to go back to the original goal, to reduce leakage of information so that we only disclose where there is a need to know. The authoritative does not need to know who is making the request. The TLD does not need to know the complete query. At some point a recursive somewhere does need to know that a query is being made. That puts client/resolver leakage in a different category to client/authoritative. Before DPRIV: anyone who owns the DNS box at an ISP can see all dns-queries go through, and know who made them. After: exactly the same. Why? Because we were lazy, and solved the easy problems instead of the worthwhile problems. After the box does not have to be at the ISP. After, you get to choose. Yes protecting that data might warrant investigation. Yes, I and others can suggest schemes that would provide that protection. No, this is not costless. No this is not a low hanging fruit. No this should not be our focus in DPRIV right now. So we shouldn't solve the problem we want to solve, because solving the problem we want to solve is hard, so we should solve the problem we can solve and fool ourselves into saying we wanted to solve it, and hope no one else notices? Put me down as thinking that this is a terrible idea. I am not at all convinced it is a problem that the world does want to solve. By which I mean , wants to solve badly enough to fund the necessary resources. I have a protocol, sure. But I don't have a business model that is likely to drive the deployment for general purpose adoption. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
