Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
CGA-TSIG is a possible solution to the secure-provisioning problem. The IPv6 CGA address contains a hash of a public key used to secure the service. If the address is provisioned in a secure manner, then the client can authenticate the resolver, by verifying that the resolver's certificate matches the hash in the IPv6 address. I am not sure that this is the best solution, but it is certainly more secure than pointing the resolver to 8.8.8.8 and later observing that this is in fact rerouted to the Turkish police. This kind of provisioning is a tradeoff. The main advantage is to not create a new provisioning channel. No need to be bothered with entering a certificate, entering the address suffices. But of course the flip side is that it only works if we update the DNS client and the resolver. If we do change the client and resolver, a number of alternatives can be used, such as: * Use the same trick as CGA but encode the hash of the certificate as a name part, e.g. AF4563ED0B561.example.com. This is probably easier to use than CGA, because names are less restricted than addresses. * Use Secure DNS, or DANE, to verify the resolver certificate. Both of these approaches have the same property of reusing an existing provisioning channel. The DANE approach is probably easier to manage, because both the hash in the address and hash in the name approaches have a hard time dealing with certificate renewal. But, yes, solving the secure provisioning issue would be nice. -- Christian Huitema ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
Hi Christian, Thanks for sharing your opinion about current approaches and also CGA-TSIG. If we do change the client and resolver, a number of alternatives can be used, such as: * Use the same trick as CGA but encode the hash of the certificate as a name part, e.g. AF4563ED0B561.example.com. This is probably easier to use than CGA, because names are less restricted than addresses. True, This is to some extend prevents exposing information and I think this is how NSEC3 works. But do you think it is applicable for resolver scenario. I think in this case we have two scenarios 1- client sends a plain text to resolver, resolver can respond to client with hashing the whole query. IN other words the whole www.example.com can be hashed and resolver can respond to the client by sending abcabcabcabc. In this case, if people here are worry about plain text, then the plain text is already exposed in client's request. 2- client cannot hash all its query. This is because the resolver does not know then what is the content of its query so that it can ask the right authoritative server. Therefore only the first scenario can happen that it still might expose information. * Use Secure DNS, or DANE, to verify the resolver certificate. Both of these approaches have the same property of reusing an existing provisioning channel. The DANE approach is probably easier to manage, because both the hash in the address and hash in the name approaches have a hard time dealing with certificate renewal. DANE might be ideal for some scenarios but I think for this scenario where we are talking about last miles of the internet (end users), the pre-configuration of clients with trusted anchor/s for certain domain might not allow unknown nodes to use this service or administrative overheads. Because a node might also move from one network to another. This is why I thought CGA-TSIG can be helpful in such scenarios. I again do not claim that it is the best approach but I think it reduces many required configuration. About generating new keys (dealing with certificate renewal), I also thought about an approach and how client or server can inform the other communicating party about the new keys. because in my proposal I tried to considered all possible situation such as dynamic environment where nodes need to change their IP address or their keys. However, I guess for DNS server, changing keys might be a rare case. In other word, what I understands from DANE, clients needs to be configured with the list of trusted anchors for certain domains. While CGA-TSIG need only the IP address of resolver or maximum the hash of public key and IP address (for IPv4). This IP address can be received either from Secure RA or from protected DHCP server or even set manually. Thanks, Best, Hosnieh ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
On Mon, Oct 27, 2014 at 08:03:48AM +, Hosnieh Rafiee hosnieh.raf...@huawei.com wrote a message of 19 lines which said: I guess you have heard about CGA-TSIG. Please do not steal threads: start a new thread (otherwise, your message will be filed under the thread I started, for some users). ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
Hi Stephane, -Original Message- From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] Sent: Monday, October 27, 2014 9:23 AM To: Hosnieh Rafiee Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy? On Mon, Oct 27, 2014 at 08:03:48AM +, Hosnieh Rafiee hosnieh.raf...@huawei.com wrote a message of 19 lines which said: I guess you have heard about CGA-TSIG. Please do not steal threads: start a new thread (otherwise, your message will be filed under the thread I started, for some users). I started a new thread with new topic without replying to your message or having the same subject as yours. This is the problem of IETF mailinglist that categorized my message automatically under your thread here http://www.ietf.org/mail-archive/web/dns-privacy/current/threads.html so, it is better that you blame mailman programmers not me! Best, Hosnieh ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
On Mon, Oct 27, 2014 at 09:55:08AM +, Hosnieh Rafiee hosnieh.raf...@huawei.com wrote a message of 28 lines which said: This is the problem of IETF mailinglist that categorized my message automatically under your thread here I strongly doubt it, since *your* message included: References: 20141027074613.ga14...@nic.fr In-Reply-To: 20141027074613.ga14...@nic.fr so, it is better that you blame mailman programmers not me! Nobody else had the problem so I think we can safely assume Mailman is correct. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
On Mon, Oct 27, 2014 at 09:55:08AM +, Hosnieh Rafiee hosnieh.raf...@huawei.com wrote a message of 28 lines which said: This is the problem of IETF mailinglist that categorized my message automatically under your thread here I strongly doubt it, since *your* message included: References: 20141027074613.ga14...@nic.fr In-Reply-To: 20141027074613.ga14...@nic.fr so, it is better that you blame mailman programmers not me! Nobody else had the problem so I think we can safely assume Mailman is correct. No not always. I saw a lot of such misleading information by mailman before in other groups as well. It appears that mailman uses a fuzzy approach and if the subject line has any similar words to the subject line of the previous thread, it categorized it under the same thread. As I said I have started a completely new message. So the header of my message was quite new and not carry any information for the old thread. For instance this one is another example of such problem. Y [dns-privacy] Authenticating the resolver, Paul Hoffman Re: [dns-privacy] Authenticating the resolver, Wes Hardaker Re: [dns-privacy] Authenticating the resolver, Paul Hoffman You can also search other groups and will see many similar cases. If this is an important problem, it is better to address fundamentally in mailman and not blaming someone who either not a programmer of a mailman or even not replied or commented the same thread. Therefore, I do not see any reason for further discussion. Hosnieh ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
On Oct 27, 2014, at 1:03 AM, Hosnieh Rafiee hosnieh.raf...@huawei.com wrote: I guess you have heard about CGA-TSIG. What do you think about the approach explained there? Is still has many confusing dependencies that make it hard to understand, and it vastly oversells the IPv4 capabilities. What do you think? It is a distraction for this WG and should not be considered. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
Hi Paul, On Oct 27, 2014, at 1:03 AM, Hosnieh Rafiee hosnieh.raf...@huawei.com wrote: I guess you have heard about CGA-TSIG. What do you think about the approach explained there? Is still has many confusing dependencies that make it hard to understand, and it vastly oversells the IPv4 capabilities. Would you please clarify the problem. I would welcome any comments to improve it and open for any comments. Of course, I need to know the exact problem that I can address it clearly. Which part of the draft is not readable? Which section needs improvements which is not easily understandable? One of the problem that I tried to address in this version is to improve readability. Joel helped me to make it readable. But if we missed anything, I need its exact section that is not well-written so that I can address it. About IP based, DNS and all other services are working on IP addresses and as far as I know they are also not behind any NAT or middle box devices that makes it impossible to verify them IP based. Resolvers also are verified at the moment on clients based on their source IP address. Now, simply the idea behind cga-tsig is just the resolver sign their messages and by verifying this signature, the bindings help to provide to authenticate this message. Then the client can use this public key of the resolver to encrypt a random value (used as a session key) and then encrypt the whole message using this random value and AES algorithm. What do you think? It is a distraction for this WG and should not be considered. There might be several solution in this regard. This draft is also simply a solution to DNS privacy (providing both authentication and required encryption easily). So why do you think it is distraction for the WG that addresses privacy? Thanks, Best, Hosnieh ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
On Oct 27, 2014, at 7:36 AM, Hosnieh Rafiee hosnieh.raf...@huawei.com wrote: So why do you think it is distraction for the WG that addresses privacy? I said I thought it was a distraction; discussing it further would be more of a distraction. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
So why do you think it is distraction for the WG that addresses privacy? I said I thought it was a distraction; discussing it further would be more of a distraction. Unfortunately, I haven't received any answer to the question that why it is distraction?. I only received ambiguous answer to the question. I do not think WG decided on any solution space , if the scope is not to have any encryption, then I agree with you. But I couldn't see anything on charter about this. Best, Hosnieh ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
On Mon, Oct 27, 2014 at 10:45 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Oct 27, 2014, at 7:36 AM, Hosnieh Rafiee hosnieh.raf...@huawei.com wrote: So why do you think it is distraction for the WG that addresses privacy? I said I thought it was a distraction; discussing it further would be more of a distraction. Which is not a polite or acceptable fashion to deal with a proposal. Like many people I have been looking at applying TSIG more generally for many years. I think the approach is architecturally sound from a security point of view but it isn't a complete solution and when you start to extend it to meet the use cases here it soon becomes apparent that reuse is hurting more than helping. TSIG is only authentication so you have to add encryption. And the original TSIG assumed keys would be passed out of band so it needs a key exchange. So lets divide the protocol into two parts, a key exchange that establishes a shared secret and some form of packaging that applies encryption and integrity operations to the DNS messages. The second part is straightforward. People can agree or disagree as to whether my attempts to optimize the transport for DNS deliver worthwhile benefits, we can argue over the specific encoding (I picked the TLS schema). But what is clear is that it should be very simple to describe and implement or its being done wrong. The key exchange is the place where the design choices come in. And here we have two approaches: 1) Reuse something already existing (CGA-TSIG, DTLS). 2) Write something new designing it so that it could be reused elsewhere. I believe the second course is the best approach in this case. I am not re-inventing the TLS crypto but I am presenting it as a JSON web service in a way that allows for reuse. CGA does not meet the use case requirements I see for the Enterprise where it has to be really easy to bind a device to a DNS service. For embedded devices it has to be 'scan a bar code' level of simplicity. And I know that we are not talking about those use cases now. And I don't really want to have to talk about those cases now either. Instead I want to have a mechanism that can be implemented very simply to meet most of the use cases and can be extended later as needed. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] What about CGA-TSIG as a solution for DNS privacy?
Hi Phillip, Thanks for your message. I tagged my message with my name since I converted it to text. TSIG is only authentication so you have to add encryption. And the original TSIG assumed keys would be passed out of band so it needs a key exchange. [Hosnieh] Yes that is true. It is only authentication. However, CGA-TSIG only used TSIG as a carrier protocol because some people told me that in this case I would need minimum changes to the protocol and like other algorithms, I can only register a new algorithm with IANA for TSIG. Therefore it can be also a separate RDATA however, to avoid compatibility I just did not think about that. So lets divide the protocol into two parts, a key exchange that establishes a shared secret and some form of packaging that applies encryption and integrity operations to the DNS messages. [Hosnieh] True. The second part is straightforward. People can agree or disagree as to whether my attempts to optimize the transport for DNS deliver worthwhile benefits, we can argue over the specific encoding (I picked the TLS schema). But what is clear is that it should be very simple to describe and implement or its being done wrong. [Hosnieh] but for TLS you probably need to have CA or preconfigured your nodes with the list of trusted anchor. This is why I thought this binding would help to minimal configuration. The key exchange is the place where the design choices come in. And here we have two approaches: 1) Reuse something already existing (CGA-TSIG, DTLS). 2) Write something new designing it so that it could be reused elsewhere. I believe the second course is the best approach in this case. I am not re-inventing the TLS crypto but I am presenting it as a JSON web service in a way that allows for reuse. CGA does not meet the use case requirements I see for the Enterprise where it has to be really easy to bind a device to a DNS service. For embedded devices it has to be 'scan a bar code' level of simplicity. [Hosnieh] It is possible that use simply a hash of (IP + key), like the networks that doesn't support CGA or SSAS or like IPv4 scenario in CGA-TSIG. Sorry that CGA-tSIG name is a bit misleading and the first interpretation of this draft is the use of CGA. However, CGA is only one of possible mechanism introduced in the draft. And I know that we are not talking about those use cases now. And I don't really want to have to talk about those cases now either. Instead I want to have a mechanism that can be implemented very simply to meet most of the use cases and can be extended later as needed. [Hosnieh] Do you have any suggestion for a simple implementations such as some required factors for implementations? I don't know how much this group would like to think about operational cases. Thanks, Best, Hosnieh ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
