On Fri, Nov 14, 2014 at 10:42 AM, Hosnieh Rafiee <[email protected]> wrote: > Hi, > > There is one question from folks. There are some existing approaches that > does not change DNS protocol. There are also new proposal that needs change > on DNS protocol. > > For example, my proposal, cga-tsig, does not change DNS protocol. So is there > any decision for the scope of solution space? >
I don't think anyone is actually proposing to change the DNS protocol. PRIVATE-DNS doesn't. Paul's might but I don't think that makes a difference. Looks to me as if you don't quite understand what my proposal does, I note the following statement in your draft: https://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-10#section-1.1.4.1 " Private DNS [private-dns] is one of privacy approaches that uses TLS and consider using JSON. To establish a secure communications, many messages needs to back and forth because the assumption is that a node itself needs to verify the TLS certificate." No, that is not at all what is going on. PRIVATE-DNS consists of a one-time device binding operation and that is the only part that involves JSON or multiple round trips. DNS lookups are stateless, single request packet, multiple response packet interactions. " - Might not have good performance (number of messages exchanged to establish this secure communication)" No, the performance os Private-DNS is optimal, there is no improvement possible over one round trip with no public key operations (or other CPU intensive operations) in the transaction loop. " - IP spoofing and MITM might be possible only when there is no CA or predefined Trusted Anchors (TA) so that it makes it possible for an attacker intercepts this communication at the beginning of TLS establishment." Obviously there needs to be some means of authenticating the service or you could be permanently binding yourself to a MITM attacker. There are two main choices: 1) For a public service then a WebPKI TLS certificate is probably the best choice. 2) For an enterprise service in which the user is issued a one time use PIN, the SXS-Connect protocol provides mutual authentication. So the client is authenticated to the server and the server to the client. I have not fully considered the case in which the device does not have a trust root built in for (2). This is important for cases such as a constrained device that might have a ten year shelf life. I have a possible solution but I have to verify it. Since this is TLS we could use any server authentication mechanism supported by TLS. For example DANE. But using DNSSEC to secure the DNS client resolver binding gives us a circular dependency issue. It would probably be better to use a direct trust model. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
