On Fri, Mar 20, 2015 at 1:01 PM, Paul Wouters <[email protected]> wrote: > On Fri, 20 Mar 2015, Watson Ladd wrote:
> If the starting point is "preconfigured public key", I see no reason why > not to use IPsec or TLS as the transport to encrypt regular DNS traffic. Good point. What is the starting point that we want for configuration of PrivateDNS? Today the user has to enter raw IP addresses or rely on the DHCP parameters. Neither is going to be acceptable as a full solution. My preference for what the user enters is a DNS name. I would then use the DHCP DNS parameters to bootstrap the system. Remember that Private DNS is likely to be introduced via application libraries before it becomes a platform feature. So any scheme that relies on DHCP parameters being visible is going to commit a layer violation. I think that all the proposals currently on the table propose the use of a DNS name as the preferred method of service identification. The difference comes in how that identification is used. The options being 1) Make use of TLS for both establishing the service connection and the presentation framing. 2) Make use of TLS to establish a service connection and then use a new presentation framing. 3) Use DNS records to establish the service connection and then use a new presentation framing. I began with approach (1) and eventually rejected it in favor of (1+2) because this is the only way to meet the performance and reliability criteria. Approach 3 certainly meets the performance criteria. I am very doubtful about its ability to meet the necessary connection criteria. For DNS Privacy to be acceptable to end users it must work 100% of the time with no iffs or buts. The only exception being the case where a MITM attacker is intentionally filtering DNS Privacy traffic. I can't see how any proposal that requires new RRs is going to meet that 100% requirement. 97% is not good enough, nor is 99%. The first time a security measure stops someone doing work it is disabled and once that happens it will never be turned back on again. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
