On Tue, Oct 14, 2014 at 10:04 AM, Paul Wouters <[email protected]> wrote:
I think Paul is being a little hard on DNSCurve here. At the time it was proposed DNSSEC had been stalled for years and looked close to being abandoned. Looking at an alternative architecture was legitimate. But that isn't the problem we are being chartered to solve. There has always been an argument as to whether transport layer or message layer security is 'right'. And the fact is that they both give different properties and achieve different things. To achieve encryption and stub-recursive authentication the appropriate approach is to look at the transport layer. To achieve authoritative-recursive or authoritative-stub authentication then the appropriate approach is to look at the message layer. In the past message layer and transport layer were seen as alternatives. In the next-gen crypto we see both as being required. > So let's use dnscurve without the NS embedded key hack, without > curve25519, and without set in stone crypto parameters. What you have > left is a statement "let's encrypt DNS packets". That has absolutely > nothing left to do with dnscurve. True, and that is what happens when we look at a 'stripped down' version of TLS. I think it is worth looking really hard at DNSCurve because it shows the limits to trying to maintain compatibility with the legacy DNS protocol on port 53. DJB makes a really good effort but he ends up having to bend the protocol left right and center to get things to fit. > doing crypto is not the hard problem. Setting up a secure channel to the > resolver is the hard problem. I think it might be unfixable unless you > only use the DHCP supplied nameserver only to reach a third party > trusted resolver elsewhere on the internet. Which is (almost) my approach. What I do is that I use the DHCP supplied nameserver to establish the initial connection to the service. The connection includes the crypto parameters and service parameters to use. Including the IP addresses and ports numbers for the hosts. The only time that the client would ever rely on DHCP DNS in future is for corner cases where the Web Service transport is being used as fallback or the host IP address was changed at some point and the client did not get the update notice. But even here the long term binding is to a set of cryptographic keys, not IP parameters. The only practical constraint on the port number is that you almost certainly don't want port 53 or any other well known port that gets interfered with by middleboxen. Since the port number is never used for discovery, there is no need to assign a well known port. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
