> > > > > Are you interested on working on CGA-TSIGe and would you like to > > > devote some (10 minutes) of the meeting time in Dallas to a > > > presentation / discussion on CGA-TSIGe? > > > > I'm not. Currently, it's really too confused for me, and backed by > > dubious claims. > > Same here, at least that was the case for me for a couple of initial revisions, > and I almost gave up trying to understand it since then. > So, to be honest, I've not read the very latest version, and I can't deny the > possibility that it now happens to be super clear and might even look the best > fit for dprive, but as someone with a quite limited amount of available time for > IETF related stuff I'd rather focus on the materials currently on the wg table. I > know I sound unfair, but that's the sad reality for me. >
I would not comment on beings fair or unfair. But what I convey from your message is like this that because something was wrong with x proposal sometime ago, I would generalize it and say it will never get better and would not like to give her/him any other chance because it is worthless. I even do not say what part of the proposal is wrong so that the person put more efforts to improve that. The clear case is that, the most current proposals are about TLS + DNS. Everyone knows how TLS works (public key cryptography + a symmetric algorithms). This is the same as CGA-TSIGe. But the only difference is that the data in TLS is sent after the session initiation. But for CGA-TSIGe, there is similar the way IPsec does but only with this difference that IPsec (tunnel mode) encapsulate the whole packet but CGA-TSIGe, only encapsulate the whole DNS message. In other word, the encapsulation is after TCP header. I agree that the first versions might be confusing. If I can recall, you have reviewed only version 7 and no other revisions made after that. During this time there were some other reviewers who commented and sent me their review offlist mostly only to help to improve it. I don't think reviewing the introduction and overview takes more than a few minutes even for people who don't have much time. Thanks, Best, Hosnieh ------------ 2. Introduction DNS messages might contain important data which might allow an attacker to analyse the behavior of users in a network or pursue further attacks. The data that might be confidential and need protection. There are recently a lot of concerns about DNS privacy and hiding the data exchanges between stub resolvers' and DNS server from prying eyes (either in active or passive attacks). This document introduces a possible solution to DNS privacy by protecting a user against privacy related attacks explained in [dns-privacy]. It does this by providing a node with a mechanism to securely verify the DNS resolver (to avoid spoofed DNS messages) and encrypt the whole DNS message. It uses the current available Resource Records (RRs) to carry any parameters requires for this process. After encryption process, this encrypted message is encapsulated in a new DNS message and the required parameters are added in the additional section of this new DNS message for decryption process in the receiver node. To address DNS data protection where it is needed (Data confidentiality), considering different factors ? automation (minimizing human interaction); secure authentication; performance; encryption, and to secure the last miles of Internet where DNSSEC cannot easily handle this protection (especially authentication during DDNS and authentication of DNS resolvers), this document Rafiee, et al. Expires August 27, 2015 [Page 4] INTERNET DRAFT New algorithms in TSIG February 27, 2015 proposes two algorithms -- one is for secure authentication that is called CGA-TSIG and one for both secure authentication and DNS data encryption (DNS privacy) that is called CGA-TSIGe. CGA-TSIGe is a mechanism to address DNS privacy issues. In DNS privacy, this document uses both asymmetric and symmetric cryptography. Asymmetric cryptography is used for encrypting the 16 byte secret key. This secret key then can be used as a key for the symmetric encryption algorithm in order to encrypt the whole DNS message. This process will increase the DNS performance by avoiding the encryption of a large DNS message using a public key cryptography. These algorithms support both IPv4 and IPv6 enabled network and considered as new algorithms in the TSIG Resource Record (RR). 2.1. Overview of CGA-TSIG/e Mechanisms - Purpose 1-secure authentication, 2-provide data confidentiality and 3-minimize human interaction required to accomplish a shared secret or key exchange. If only number 1 and 2 is the purpose, then the algorithm is called CGA-TSIG. When 1,2, and 3 all together is the purpose, then the algorithm is called CGA-TSIGe It uses the same port as DNS protocol, therefore, there is no need to change any middle boxes to adapt them to this proposal. The installation of this mechanism on client and server is enough. Since this protocol is added to "Other Data" section of TSIG RR, when a DNS client or server does not support CGA-TSIG, it easily ignores CGA-TSIG option without returning any error and returns back to compatibility mode, i.e., using DNS server without encryption. - How client and server receives the IP address/hash of public key of DNS server? There are two possibilities: 1- From a DNS option in router advertisement message [RFC6106] 2- From a DHCP/v6 server protected via SAVI approaches [savi-dhcp] or any monitoring node - What if the network is not trusted (e.g. untrusted DHCP server, untrusted router, untrusted DNS server) This is only applicable for resolver scenario. User can easily introduce the IP address of trusted resolver (or select home resolver from the list of trusted resolvers in its computer). For automation purpose, the implementation SHOULD provide a possibility to store a short list of trusted resolvers so that the client can pick one of them. Rafiee, et al. Expires August 27, 2015 [Page 5] INTERNET DRAFT New algorithms in TSIG February 27, 2015 - How CGA-TSIG/e Prevents Spoofing and authenticate DNS servers or clients (depends on scenario) In the IPv6 scenario, the algorithms use Cryptographically Generated Addresses (CGA) [RFC3972] or Secure Simple Addressing Scheme for IPv6 Autoconfiguration (SSAS) [4, 5]. Both CGA and SSAS provide the nodes with the necessary proof of IP address ownership by providing a cryptographic binding between a host's public key and its IP address without the need for the introduction of infrastructure. In other word, by receiving any message from a DNS resolver, client can verify its signature and since the key is bound to the IP address, the client can make sure that the value is from the same resolver as it already received the IP address from DHCP server or an option in router advertisement message. In IPv4 scenarios, the algorithms use the hash of public key as an authentication approach. For example, in resolver scenario, the client receives the DNS resolver?s hash of (IPv4 + public key) from a DHCPv4 server that is protected by SAVI approaches or other monitoring approaches. When the client receives the key from DNS server it calculates the hash of (IPv4 + public key) and compare this value with what it received from DHCP server. If it matches, then the client can trust any value received from the DNS server. - How Client and server do key exchange Client sends an empty message and adding TSIG in additional part and set the algorithm to CGA-TSIGe. This message then can be sent to DNS server. DNS server then knows it should submit its key to client, sign it with its own private key. - In CGA-TSIGe, if the whole message is encrypted, How the DNS server knows how to decrypt the message After a client receives the public key of DNS server in a secure manner (as explained in prior paragraphs), it generates a random number and call this number a secret key (it is similar to session key in TLS or SSL). It, then, encrypts the whole DNS message and encapsulate it in a new DNS message (that is adding new header and additional section). In additional section of this new DNS message, it includes CGA-TSIGe and all its required parameters. In other word, the whole encrypted messages is like a query section in new DNS message. Then the secret key is encrypted using the public key of DNS server and this message is submitted to the DNS server. When the DNS server receives this message, if the additional section includes CGA-TSIGe, then it first decrypts the secret key using Rafiee, et al. Expires August 27, 2015 [Page 6] INTERNET DRAFT New algorithms in TSIG February 27, 2015 public key cryptography and then decrypts the whole DNS message using this secret key and a symmetric algorithm such as AES. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
