On Tue, 14 Oct 2014, Mukund Sivaraman wrote:
Will you explain why stub-resolver communication cannot be secured with the concepts in DNSCurve? The NS record would not apply, but I don't see anything in the packet formats itself that would make it useless.
dnscurve is based on talking to the crypto keys from the NS records on authoritative servers. You cannot have intermediaries unless you fully trust those to relay data unmodified. Dan made some wild and provenly incorrect claims about "dns cache being obsolete anyway" and has made no attempt with his protocols to allow secure (encrypted and authenticated) communication between a resolver and a stub.
Any other scheme would also require key distribution of either a shared key or a public key between resolver and stub. Are there additional requirements apart from transport security?
Of course, the fundamental problem with dns privacy between the resolver and the stub is that there is no prior trust relationship. Even crypto keys wouldn't help you trust the resolver, it could only help you talk to the untrusted resolver privately at best.
Even though DNSCurve in its current form has issues, I don't think it's right to dismiss it from discussion and not take ideas from it.
I understand your wish for dnscurve to be useful, but it is unfortunately not more than that. dnscurve authenticates and encrypts traffic from stub to auth servers. It's core to its design. If you take that away, you are left with "some specific ECC curve encryption". There is simply nothing left to "take from" dnscurve. It's like saying the use of green camouflage clothing provides security and privacy agaist distant enemies in the woods, so we should try to use it as well for close combat on the blue water.
The central idea in DNSCurve is that the DNS message goes into a safe box and the receiver uses the associated crypto params in the packet to open the box and use the DNS message in it.
We normally call that idea "encryption". And all the mentioned proposals for dns privacy already include encryption in one way or the other.
There is no prior handshake required
No prior handshake depends on 1) having a trusted relationship with its parent using dnscurve or a hardcoded key and 2) not using intermediary dns servers. Unfortuantely, the main use case for dns privacy here IS the cse where we depend on an intermediary player.
, and you can have 1 datagram query -> 1 datagram reply.
Every solution can do that, once you have setup the crypto handshake. Your "1 query and 1 reply" depends on you already knowing the NS-embedded key of the parent of the query you are doing now. It's a very artificial scenario.
It may use DJB's crypto and fixed key sizes in the 2 packet types in the draft, but each packet has the type identifier in the header. Nothing stops adding additional types with different algorithms, keysizes and nonces, keeping the concept of the dns-message-in-a-box.
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. 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. Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
