From nobody Fri Feb 14 14:04:29 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2782F1A00B0; Fri, 14 Feb 2014 14:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBopjzHqelyx; Fri, 14 Feb 2014 14:04:16 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id ADA231A00C6; Fri, 14 Feb 2014 14:04:07 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 112EB800AA; Fri, 14 Feb 2014 17:04:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1392415446; bh=JuzXP6NxPTww83ldK7QDSX+LF/HTlY1p8P1TSwfTX6A=; h=Date:From:To:cc:Subject; b=t+Qu/BFrtFE2ng7IZOn1xCkOvJIKzhcjqO+s4ThJ2fGD/jlEQkt98IDNDerUrrnJ+ n7uOywd6M8JYDILv/pXzR1AlnRJApwj1ldyOcEm5YBm1ksSJJwhPNaUalAtQhbo+Oe qR0kUDYYGh3vaajBTgIp/Rh9uVT/0wLVLfjvkd9w= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1EM45sb016374; Fri, 14 Feb 2014 17:04:05 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 14 Feb 2014 17:04:05 -0500 (EST) From: Paul Wouters To: DNSEXT Group Working Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/y1Cl9B_rvf7b-zOCjZmqanhTDLs Cc: dnsop Subject: [dnsext] updated draft-wouters-edns-chain-query and draft-wouters-edns-tcp-keepalive X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:04:22 -0000 Due to lack of a WG list, sent to dnsop and dnsext I've updated two drafts: https://datatracker.ietf.org/doc/draft-wouters-edns-tcp-keepalive/ By popular request, the TIMEOUT value can now be used by both clients and servers to manage their resources and expectations. Various people requested we should not be too strict on anycast servers, and we no longer require them to only use a TIMEOUT of 0. Addressed comments from Ray, Mark, Tatuya, and others, and findings of me as a result of testing using a patched dig against common DNS servers capability to keep TCP sessions open already. Reference the problem of 5966 recommending closing idle TCP sessions in seconds. https://datatracker.ietf.org/doc/draft-wouters-edns-chain-query/ (formerly draft-wouters-edns-tcp-chain-query) Most importantly, it no longer requires TCP, but will allow any "source ip validated" transport, and references draft-eastlake-cookies for UDP. Addresses Marc's comment regarding DNS requests > 512 bytes Clarifies why we want NS records (in case we switch from forwarder to standalone recursive) Update on justification why this is better than rapid-fire UDP. Paul From nobody Fri Feb 14 15:08:04 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B434D1A0459; Fri, 14 Feb 2014 15:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHYzjm80mqon; Fri, 14 Feb 2014 15:07:42 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 878AD1A0450; Fri, 14 Feb 2014 15:07:37 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 5529823E24C2; Fri, 14 Feb 2014 23:07:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_TVKLuP8jKQ; Sat, 15 Feb 2014 00:07:33 +0100 (CET) Received: from kopoli (f052005189.adsl.alicedsl.de [78.52.5.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id EFF8F23E24BC; Sat, 15 Feb 2014 00:07:32 +0100 (CET) From: "Hosnieh Rafiee" To: , Date: Sat, 15 Feb 2014 00:07:31 +0100 Message-ID: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8p2Ydc1m63NpXkQOSaC46ODJ+WHQ== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/x1rG2r17y6RBBqmb2Z8ovnwJ09Q Cc: 'Jeroen van der Ham' Subject: Re: [dnsext] CGA-TSIG - new version X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:07:47 -0000 Thanks for the information you've provided, I improved the document according to comments and found out that the report also has a few problems which is due to the fact that it misinterpreted the of CGA-TSIG document. Here I explain the problems or the reasons of choices: - CGA-TSIG cannot use MAC as a signature field. The purpose was that to have all the CGA data in one section instead of trying to find them in different sections of TSIG. - sizes of length encoding: It is one byte. It is enough for any key sizes. If you also check the "checksum" field in the packets, you will find out that it is only 8 bits or one byte. In the emails I explained to you that it is the multiple of 8. In no RFC you can find out that the value is the length of data in bits. It is always the length of data in bytes. But how you showed in your report is that you consider the number of bits and not bytes so you had the following example 2048/8=256 (now you only converted the number of bits to bytes) so you needed to divide it by another 8 that is 256/8=32 and this is the value you set to length. If you even consider the key size 7680, then the length will be only 120. nd - old signature only contains time signed. The reason is to avoid increasing the packet length I appreciate further comments and would like more people review it so that we can go ahead with this document. Thanks, Hosnieh A new version of I-D, draft-rafiee-intarea-cga-tsig-07.txt has been successfully submitted by Hosnieh Rafiee and posted to the IETF repository. Name: draft-rafiee-intarea-cga-tsig Revision: 07 Title: Secure DNS Authentication using CGA/SSAS Algorithm in IPv6 Document date: 2014-02-15 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-07.txt Status: https://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/ Htmlized: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-07 Diff: http://www.ietf.org/rfcdiff?url2=draft-rafiee-intarea-cga-tsig-07 Abstract: This document describes a new mechanism that can be used to reduce the need for human intervention during DNS authentication and secure DNS authentication in various scenarios such as the DNS authentication of resolvers to stub resolvers, authentication during zone transfers, authentication of root DNS servers to recursive DNS servers, and authentication during the FQDN (RFC 4703) update. Especially in the last scenario, i.e., FQDN, if the node uses the Neighbor Discovery Protocol (NDP) (RFC 4861, RFC 4862), unlike the Dynamic Host Configuration Protocol (DHCP) (RFC 3315), the node has no way of updating his FQDN records on the DNS and has no means for a secure authentication with the DNS server. While this is a major problem in NDP-enabled networks, this is a minor problem in DHCPv6. This is because the DHCP server updates the FQDN records on behalf of the nodes on the network. This document also introduces a possible algorithm for DNS data confidentiality. > -----Original Message----- > From: dnsext [mailto:dnsext-bounces@ietf.org] On Behalf Of Marc Buijsman > Sent: Thursday, January 16, 2014 3:45 PM > To: dnsext@ietf.org > Cc: Jeroen van der Ham > Subject: [dnsext] CGA-TSIG research report > > Dear working group members, > > For my master's thesis I have performed an investigation at NLnet Labs on > CGA-TSIG as a solution to the last mile problem of DNS. The version of the > CGA-TSIG proposal that I reviewed is the current latest version at > http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-06. During the course of > my research I have already had some contact with Ms. Rafiee. > > In order to do a verification of the CGA-TSIG proposal I have created a proof > of concept implementation in NLnet Labs' "ldns" library. Since the scope of > the project was limited to the last mile problem it only includes the code > required for this purpose, but the implementation could easily be extended > to support other applications (like zone transfers). I have found that CGA-TSIG > has potential to be an adequate solution to the last mile problem on IPv6 > networks, although some future research is needed with regard to > bootstrapping the authentication. > > As a result, I would hereby like to refer you to my report which can be found > at http://www.nlnetlabs.nl/downloads/publications/report-rp2-buijsman.pdf. > I have outlined my results in section 4.2 which contains suggestions on how I > believe the CGA-TSIG draft could be clarified and otherwise improved. I hope > my suggestions will be adopted in the next version of the draft. The PoC code > can be found in the online Git repository of NLnet Labs at > http://git.nlnetlabs.nl/ldns/?h=cga-tsig. > > I hope my work will be helpful in standardising CGA-TSIG. > > Yours sincerely, > > Marc Buijsman > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From nobody Sat Feb 15 12:16:51 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D70B1A0297; Sat, 15 Feb 2014 12:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wUjT6Jo9nsy; Sat, 15 Feb 2014 12:16:42 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id DF6F01A028A; Sat, 15 Feb 2014 12:16:41 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 9B00323E24C2; Sat, 15 Feb 2014 20:16:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKnf0uqF-dNm; Sat, 15 Feb 2014 21:16:37 +0100 (CET) Received: from kopoli (g226188167.adsl.alicedsl.de [92.226.188.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 4F1AB23E24BC; Sat, 15 Feb 2014 21:16:37 +0100 (CET) From: "Hosnieh Rafiee" To: , Date: Sat, 15 Feb 2014 21:16:35 +0100 Message-ID: <001601cf2a8a$d39b7db0$7ad27910$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8qitKEr99V05bSR9Kkz6v/ha91lQ== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/qvya5v3ZjhNA5Y0PAiw3KrJtOi0 Subject: Re: [dnsext] draft-rafiee-intarea-cga-tsig-07 - X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 20:16:47 -0000 Follow up, I forgot to mention that, this document also provide a possible solution for DNS data confidentiality (for IPv6 enabled networks) to protect users' privacy in a very simple step. It does not need TLS for doing this like other draft in the mailing list. Please take a look and comment on it. Hosnieh > > A new version of I-D, draft-rafiee-intarea-cga-tsig-07.txt > has been successfully submitted by Hosnieh Rafiee and posted to the IETF > repository. > > Name: draft-rafiee-intarea-cga-tsig > Revision: 07 > Title: Secure DNS Authentication using CGA/SSAS Algorithm in IPv6 > Document date: 2014-02-15 > Group: Individual Submission > Pages: 26 > URL: > http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-07.txt > Status: > https://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/ > Htmlized: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-07 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-rafiee-intarea-cga-tsig-07 > > Abstract: > This document describes a new mechanism that can be used to reduce > the need for human intervention during DNS authentication and secure > DNS authentication in various scenarios such as the DNS > authentication of resolvers to stub resolvers, authentication during > zone transfers, authentication of root DNS servers to recursive DNS > servers, and authentication during the FQDN (RFC 4703) update. > > Especially in the last scenario, i.e., FQDN, if the node uses the > Neighbor Discovery Protocol (NDP) (RFC 4861, RFC 4862), unlike the > Dynamic Host Configuration Protocol (DHCP) (RFC 3315), the node has > no way of updating his FQDN records on the DNS and has no means for a > secure authentication with the DNS server. While this is a major > problem in NDP-enabled networks, this is a minor problem in DHCPv6. > This is because the DHCP server updates the FQDN records on behalf of > the nodes on the network. This document also introduces a possible > algorithm for DNS data confidentiality. > > > From nobody Sun Feb 16 03:12:05 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AD71A01B6; Sun, 16 Feb 2014 03:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQhIm56oy9rQ; Sun, 16 Feb 2014 03:12:01 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 54EBC1A0199; Sun, 16 Feb 2014 03:12:01 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 6FFD617B9A8; Sun, 16 Feb 2014 12:11:58 +0100 (CET) Received: from [192.168.1.2] (178-84-162-64.dynamic.upc.nl [178.84.162.64]) by smtp.os3.nl (Postfix) with ESMTPSA id 6132817B99E; Sun, 16 Feb 2014 12:11:58 +0100 (CET) Message-ID: <53009CFE.9030900@os3.nl> Date: Sun, 16 Feb 2014 12:11:58 +0100 From: Marc Buijsman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hosnieh Rafiee References: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> In-Reply-To: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/Nue2bZbmipGWB9Ewt5pZJDNFHhQ Cc: 'Jeroen van der Ham' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] CGA-TSIG - new version X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 11:12:04 -0000 Dear Hosnieh, First of all, I'm glad I could be of help and to see that a number of my suggestions have been adopted! Regarding the size of the length fields, however, I'm still confused by what you are trying to say. I did not consider the number of bits, I really considered the number of bytes (octets). If I wanted to encode the length in bits (and I don't), I would have set the value to 2048. But I'm dividing by 8 and set the value to 256 instead, which is the length in *bytes* as you said yourself. The reason why you divide by 8 a second time is a mystery to me. The outcome would then be the number of groups of 8 bytes, but I've never seen a length encoding before that counts such 'octobytes' (which is not a byte, but 8 bytes). So you are counting 32 octobytes, while I am counting 256 bytes (as usual). Also, I don't understand what you mean to say by "multiple of 8". If the encoding would be in bits (and again, it's not) and the data is always a number of whole bytes, then yes the value would be a multiple of 8. But we are talking about an encoding in bytes here, which do not necessarily come in groups of 8 (and is therefore not necessarily a multiple of 8). I also don't know what checksum fields you mean or how their length is relevant here, but the IPv4 header checksum field and UDP checksum field in a regular DNS packet are two bytes each. With regard to the old signature: how would including more fields in the digest operation increase the packet size? No matter how many fields you digest, the resulting signature is always of the same length. And the fields I was referring to are already part of the packet. In order to be able to authenticate the new public key, you MUST at least include the new public key in the digest operation. Otherwise the packet could be intercepted and the new public key could be replaced without notice. Kind regards, Marc Buijsman Hosnieh Rafiee schreef op 15-2-2014 0:07: > Thanks for the information you've provided, I improved the document > according to comments and found out that the report also has a few problems > which is due to the fact that it misinterpreted the of CGA-TSIG document. > > Here I explain the problems or the reasons of choices: > > - CGA-TSIG cannot use MAC as a signature field. The purpose was that to have > all the CGA data in one section instead of trying to find them in different > sections of TSIG. > > - sizes of length encoding: It is one byte. It is enough for any key sizes. > If you also check the "checksum" field in the packets, you will find out > that it is only 8 bits or one byte. In the emails I explained to you that it > is the multiple of 8. In no RFC you can find out that the value is the > length of data in bits. It is always the length of data in bytes. But how > you showed in your report is that you consider the number of bits and not > bytes so you had the following example > 2048/8=256 (now you only converted the number of bits to bytes) so you > needed to divide it by another 8 that is 256/8=32 and this is the value you > set to length. If you even consider the key size 7680, then the length will > be only 120. > nd > - old signature only contains time signed. The reason is to avoid increasing > the packet length > > I appreciate further comments and would like more people review it so that > we can go ahead with this document. > > Thanks, > Hosnieh > > > > A new version of I-D, draft-rafiee-intarea-cga-tsig-07.txt > has been successfully submitted by Hosnieh Rafiee and posted to the IETF > repository. > > Name: draft-rafiee-intarea-cga-tsig > Revision: 07 > Title: Secure DNS Authentication using CGA/SSAS Algorithm in IPv6 > Document date: 2014-02-15 > Group: Individual Submission > Pages: 26 > URL: > http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-07.txt > Status: > https://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/ > Htmlized: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-07 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-rafiee-intarea-cga-tsig-07 > > Abstract: > This document describes a new mechanism that can be used to reduce > the need for human intervention during DNS authentication and secure > DNS authentication in various scenarios such as the DNS > authentication of resolvers to stub resolvers, authentication during > zone transfers, authentication of root DNS servers to recursive DNS > servers, and authentication during the FQDN (RFC 4703) update. > > Especially in the last scenario, i.e., FQDN, if the node uses the > Neighbor Discovery Protocol (NDP) (RFC 4861, RFC 4862), unlike the > Dynamic Host Configuration Protocol (DHCP) (RFC 3315), the node has > no way of updating his FQDN records on the DNS and has no means for a > secure authentication with the DNS server. While this is a major > problem in NDP-enabled networks, this is a minor problem in DHCPv6. > This is because the DHCP server updates the FQDN records on behalf of > the nodes on the network. This document also introduces a possible > algorithm for DNS data confidentiality. > > > > > > > > >> -----Original Message----- >> From: dnsext [mailto:dnsext-bounces@ietf.org] On Behalf Of Marc Buijsman >> Sent: Thursday, January 16, 2014 3:45 PM >> To: dnsext@ietf.org >> Cc: Jeroen van der Ham >> Subject: [dnsext] CGA-TSIG research report >> >> Dear working group members, >> >> For my master's thesis I have performed an investigation at NLnet Labs on >> CGA-TSIG as a solution to the last mile problem of DNS. The version of the >> CGA-TSIG proposal that I reviewed is the current latest version at >> http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-06. During the > course of >> my research I have already had some contact with Ms. Rafiee. >> >> In order to do a verification of the CGA-TSIG proposal I have created a > proof >> of concept implementation in NLnet Labs' "ldns" library. Since the scope > of >> the project was limited to the last mile problem it only includes the code >> required for this purpose, but the implementation could easily be extended >> to support other applications (like zone transfers). I have found that > CGA-TSIG >> has potential to be an adequate solution to the last mile problem on IPv6 >> networks, although some future research is needed with regard to >> bootstrapping the authentication. >> >> As a result, I would hereby like to refer you to my report which can be > found >> at http://www.nlnetlabs.nl/downloads/publications/report-rp2-buijsman.pdf. >> I have outlined my results in section 4.2 which contains suggestions on > how I >> believe the CGA-TSIG draft could be clarified and otherwise improved. I > hope >> my suggestions will be adopted in the next version of the draft. The PoC > code >> can be found in the online Git repository of NLnet Labs at >> http://git.nlnetlabs.nl/ldns/?h=cga-tsig. >> >> I hope my work will be helpful in standardising CGA-TSIG. >> >> Yours sincerely, >> >> Marc Buijsman >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext From nobody Sun Feb 16 03:41:38 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D520E1A03D6; Sun, 16 Feb 2014 03:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXSSh-n4bvzT; Sun, 16 Feb 2014 03:41:34 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id BFCC01A03D5; Sun, 16 Feb 2014 03:41:33 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 4773B23E2D48; Sun, 16 Feb 2014 11:41:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIhpjMQ7utCt; Sun, 16 Feb 2014 12:41:28 +0100 (CET) Received: from kopoli (g225015008.adsl.alicedsl.de [92.225.15.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 1CB5823E2B25; Sun, 16 Feb 2014 12:41:28 +0100 (CET) From: "Hosnieh Rafiee" To: "'Marc Buijsman'" References: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> <53009CFE.9030900@os3.nl> In-Reply-To: <53009CFE.9030900@os3.nl> Date: Sun, 16 Feb 2014 12:41:26 +0100 Message-ID: <003a01cf2b0c$067d2360$13776a20$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQOKWVpFurMI2Qzh8V0RHyHseiUo8gI85gZYly97AHA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/ckrYquJ2tOZ3DKBuwNJVpTYu-Uw Cc: 'Jeroen van der Ham' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] CGA-TSIG - new version X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 11:41:37 -0000 Dear Marc, Thanks for your comments. > > Regarding the size of the length fields, however, I'm still confused by what you > are trying to say. I did not consider the number of bits, I really considered the > number of bytes (octets). If I wanted to encode the length in bits (and I don't), > I would have set the value to 2048. > But I'm dividing by 8 and set the value to 256 instead, which is the length in > *bytes* as you said yourself. The reason why you divide by 8 a second time is > a mystery to me. The outcome would then be the number of groups of 8 > bytes, but I've never seen a length encoding before that counts such > 'octobytes' (which is not a byte, but 8 bytes). So you are counting 32 > octobytes, while I am counting 256 bytes (as usual). > Also, I don't understand what you mean to say by "multiple of 8". If the > encoding would be in bits (and again, it's not) and the data is always a number > of whole bytes, then yes the value would be a multiple of 8. But we are talking > about an encoding in bytes here, which do not necessarily come in groups of > 8 (and is therefore not necessarily a multiple of 8). > I also don't know what checksum fields you mean or how their length is > relevant here, but the IPv4 header checksum field and UDP checksum field in > a regular DNS packet are two bytes each. http://tools.ietf.org/html/rfc3971#section-5.1 maybe my wording is not correct. Check the length field here. 8 bits is really not enough for that. So, If you check the implementation of SeNDs (Docomo, etc). what they do is they shift the values or easier way is to divide by 8. > With regard to the old signature: how would including more fields in the > digest operation increase the packet size? No matter how many fields you > digest, the resulting signature is always of the same length. And the fields I was > referring to are already part of the packet. In order to be able to authenticate > the new public key, you MUST at least include the new public key in the digest > operation. Otherwise the packet could be intercepted and the new public key > could be replaced without notice. You're not talking about SHA1 digest, you're talking about digital signature. It depends on the input data. This is why , for example, in SeND they included padding at the end that this value can be the multiple of 8. If this value had a fixed size, they would not include any length to it. In RFCs they usually include lengths when the length of value is variable and without length field, one cannot determine the length. http://tools.ietf.org/html/rfc3971#section-5.2 So, this value is not actually the same size and depends on the plain text that one wants to sign. Secondly, if you check the content of the signature, you will notice that I included all the DNS message and it is not like before. Because the new signature is verified before old signature, no replay attack can be happened since the new signature verification will be failed. So no need to sign a large data for old signature field and only timestamp or a small value is enough just to show that this node is the owner of this public key. To avoid replay attack again, I consider to sign the timestamp. I hope this answer your questions. Thanks, Best, Hosnieh > Kind regards, > > Marc Buijsman > > Hosnieh Rafiee schreef op 15-2-2014 0:07: > > Thanks for the information you've provided, I improved the document > > according to comments and found out that the report also has a few > > problems which is due to the fact that it misinterpreted the of CGA-TSIG > document. > > > > Here I explain the problems or the reasons of choices: > > > > - CGA-TSIG cannot use MAC as a signature field. The purpose was that > > to have all the CGA data in one section instead of trying to find them > > in different sections of TSIG. > > > > - sizes of length encoding: It is one byte. It is enough for any key sizes. > > If you also check the "checksum" field in the packets, you will find > > out that it is only 8 bits or one byte. In the emails I explained to > > you that it is the multiple of 8. In no RFC you can find out that the > > value is the length of data in bits. It is always the length of data > > in bytes. But how you showed in your report is that you consider the > > number of bits and not bytes so you had the following example > > 2048/8=256 (now you only converted the number of bits to bytes) so you > > needed to divide it by another 8 that is 256/8=32 and this is the > > value you set to length. If you even consider the key size 7680, then > > the length will be only 120. > > nd > > - old signature only contains time signed. The reason is to avoid > > increasing the packet length > > > > I appreciate further comments and would like more people review it so > > that we can go ahead with this document. > > > > Thanks, > > Hosnieh > > > > > > > > A new version of I-D, draft-rafiee-intarea-cga-tsig-07.txt > > has been successfully submitted by Hosnieh Rafiee and posted to the > > IETF repository. > > > > Name: draft-rafiee-intarea-cga-tsig > > Revision: 07 > > Title: Secure DNS Authentication using CGA/SSAS Algorithm in IPv6 > > Document date: 2014-02-15 > > Group: Individual Submission > > Pages: 26 > > URL: > > http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-07.t > > xt > > Status: > > https://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/ > > Htmlized: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-07 > > Diff: > > http://www.ietf.org/rfcdiff?url2=draft-rafiee-intarea-cga-tsig-07 > > > > Abstract: > > This document describes a new mechanism that can be used to reduce > > the need for human intervention during DNS authentication and secure > > DNS authentication in various scenarios such as the DNS > > authentication of resolvers to stub resolvers, authentication during > > zone transfers, authentication of root DNS servers to recursive DNS > > servers, and authentication during the FQDN (RFC 4703) update. > > > > Especially in the last scenario, i.e., FQDN, if the node uses the > > Neighbor Discovery Protocol (NDP) (RFC 4861, RFC 4862), unlike the > > Dynamic Host Configuration Protocol (DHCP) (RFC 3315), the node has > > no way of updating his FQDN records on the DNS and has no means for a > > secure authentication with the DNS server. While this is a major > > problem in NDP-enabled networks, this is a minor problem in DHCPv6. > > This is because the DHCP server updates the FQDN records on behalf of > > the nodes on the network. This document also introduces a possible > > algorithm for DNS data confidentiality. > > > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: dnsext [mailto:dnsext-bounces@ietf.org] On Behalf Of Marc > >> Buijsman > >> Sent: Thursday, January 16, 2014 3:45 PM > >> To: dnsext@ietf.org > >> Cc: Jeroen van der Ham > >> Subject: [dnsext] CGA-TSIG research report > >> > >> Dear working group members, > >> > >> For my master's thesis I have performed an investigation at NLnet > >> Labs on CGA-TSIG as a solution to the last mile problem of DNS. The > >> version of the CGA-TSIG proposal that I reviewed is the current > >> latest version at > >> http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-06. During > >> the > > course of > >> my research I have already had some contact with Ms. Rafiee. > >> > >> In order to do a verification of the CGA-TSIG proposal I have created > >> a > > proof > >> of concept implementation in NLnet Labs' "ldns" library. Since the > >> scope > > of > >> the project was limited to the last mile problem it only includes the > >> code required for this purpose, but the implementation could easily > >> be extended to support other applications (like zone transfers). I > >> have found that > > CGA-TSIG > >> has potential to be an adequate solution to the last mile problem on > >> IPv6 networks, although some future research is needed with regard to > >> bootstrapping the authentication. > >> > >> As a result, I would hereby like to refer you to my report which can > >> be > > found > >> at http://www.nlnetlabs.nl/downloads/publications/report-rp2- > buijsman.pdf. > >> I have outlined my results in section 4.2 which contains suggestions > >> on > > how I > >> believe the CGA-TSIG draft could be clarified and otherwise improved. > >> I > > hope > >> my suggestions will be adopted in the next version of the draft. The > >> PoC > > code > >> can be found in the online Git repository of NLnet Labs at > >> http://git.nlnetlabs.nl/ldns/?h=cga-tsig. > >> > >> I hope my work will be helpful in standardising CGA-TSIG. > >> > >> Yours sincerely, > >> > >> Marc Buijsman > >> _______________________________________________ > >> dnsext mailing list > >> dnsext@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsext From nobody Sun Feb 16 04:10:23 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F841A03E5; Sun, 16 Feb 2014 04:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn9NxYdc0V4Y; Sun, 16 Feb 2014 04:10:16 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 480E01A00FF; Sun, 16 Feb 2014 04:10:16 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 2F30E23E2D48; Sun, 16 Feb 2014 12:10:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI2Kq0GiCWjr; Sun, 16 Feb 2014 13:10:11 +0100 (CET) Received: from kopoli (g225015008.adsl.alicedsl.de [92.225.15.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id C67E923E2B25; Sun, 16 Feb 2014 13:10:10 +0100 (CET) From: "Hosnieh Rafiee" To: "'Marc Buijsman'" References: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> <53009CFE.9030900@os3.nl> <003a01cf2b0c$067d2360$13776a20$@rozanak.com> In-Reply-To: <003a01cf2b0c$067d2360$13776a20$@rozanak.com> Date: Sun, 16 Feb 2014 13:10:08 +0100 Message-ID: <003b01cf2b10$091fbde0$1b5f39a0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQOKWVpFurMI2Qzh8V0RHyHseiUo8gI85gZYAcBsuHqXIYESAA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/Q7sXwTTjelWNXeIYX7DG448Omvs Cc: 'Jeroen van der Ham' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] CGA-TSIG - new version X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 12:10:20 -0000 Follow up, I thought again about the possible attacks scenarios. I concluded that I also need to include the new public key in the content of the old signature. This means the old signature should be "new public key + timestamp", otherwise the attacker might have a possibility (a few seconds) to do the replay attack by copying the old public key and oldsignature. So, you're right, it still might cause the attacker to attack. But to avoid increasing packet size, it is only enough for the two values that is new public key and timestamp. Since the new public key is verified by both CGA verification process and also the new signature and the old public key is verified by old signature. I will correct this in the next version of the document. Thanks, Best, Hosnieh > -----Original Message----- > From: dnsext [mailto:dnsext-bounces@ietf.org] On Behalf Of Hosnieh Rafiee > Sent: Sunday, February 16, 2014 12:41 PM > To: 'Marc Buijsman' > Cc: 'Jeroen van der Ham'; DNSOP@ietf.org; dnsext@ietf.org > Subject: Re: [dnsext] CGA-TSIG - new version > > Dear Marc, > > Thanks for your comments. > > > > > Regarding the size of the length fields, however, I'm still confused > > by > what you > > are trying to say. I did not consider the number of bits, I really > considered the > > number of bytes (octets). If I wanted to encode the length in bits > > (and I > don't), > > I would have set the value to 2048. > > But I'm dividing by 8 and set the value to 256 instead, which is the > length in > > *bytes* as you said yourself. The reason why you divide by 8 a second > > time > is > > a mystery to me. The outcome would then be the number of groups of 8 > > bytes, but I've never seen a length encoding before that counts such > > 'octobytes' (which is not a byte, but 8 bytes). So you are counting 32 > > octobytes, while I am counting 256 bytes (as usual). > > > > Also, I don't understand what you mean to say by "multiple of 8". If > > the encoding would be in bits (and again, it's not) and the data is > > always a > number > > of whole bytes, then yes the value would be a multiple of 8. But we > > are > talking > > about an encoding in bytes here, which do not necessarily come in > > groups > of > > 8 (and is therefore not necessarily a multiple of 8). > > I also don't know what checksum fields you mean or how their length is > > relevant here, but the IPv4 header checksum field and UDP checksum > > field > in > > a regular DNS packet are two bytes each. > > http://tools.ietf.org/html/rfc3971#section-5.1 > maybe my wording is not correct. Check the length field here. 8 bits is really > not enough for that. So, If you check the implementation of SeNDs (Docomo, > etc). what they do is they shift the values or easier way is to divide by 8. > > > With regard to the old signature: how would including more fields in > > the digest operation increase the packet size? No matter how many > > fields you digest, the resulting signature is always of the same > > length. And the > fields I was > > referring to are already part of the packet. In order to be able to > authenticate > > the new public key, you MUST at least include the new public key in > > the > digest > > operation. Otherwise the packet could be intercepted and the new > > public > key > > could be replaced without notice. > > You're not talking about SHA1 digest, you're talking about digital signature. It > depends on the input data. This is why , for example, in SeND they included > padding at the end that this value can be the multiple of 8. > If this value had a fixed size, they would not include any length to it. In RFCs > they usually include lengths when the length of value is variable and without > length field, one cannot determine the length. > http://tools.ietf.org/html/rfc3971#section-5.2 > So, this value is not actually the same size and depends on the plain text that > one wants to sign. > Secondly, if you check the content of the signature, you will notice that I > included all the DNS message and it is not like before. Because the new > signature is verified before old signature, no replay attack can be happened > since the new signature verification will be failed. So no need to sign a large > data for old signature field and only timestamp or a small value is enough just > to show that this node is the owner of this public key. To avoid replay attack > again, I consider to sign the timestamp. > > I hope this answer your questions. > > > Thanks, > Best, > Hosnieh > > > Kind regards, > > > > Marc Buijsman > > > > Hosnieh Rafiee schreef op 15-2-2014 0:07: > > > Thanks for the information you've provided, I improved the document > > > according to comments and found out that the report also has a few > > > problems which is due to the fact that it misinterpreted the of > > > CGA-TSIG > > document. > > > > > > Here I explain the problems or the reasons of choices: > > > > > > - CGA-TSIG cannot use MAC as a signature field. The purpose was that > > > to have all the CGA data in one section instead of trying to find > > > them in different sections of TSIG. > > > > > > - sizes of length encoding: It is one byte. It is enough for any key > sizes. > > > If you also check the "checksum" field in the packets, you will find > > > out that it is only 8 bits or one byte. In the emails I explained to > > > you that it is the multiple of 8. In no RFC you can find out that > > > the value is the length of data in bits. It is always the length of > > > data in bytes. But how you showed in your report is that you > > > consider the number of bits and not bytes so you had the following > > > example > > > 2048/8=256 (now you only converted the number of bits to bytes) so > > > you needed to divide it by another 8 that is 256/8=32 and this is > > > the value you set to length. If you even consider the key size 7680, > > > then the length will be only 120. > > > nd > > > - old signature only contains time signed. The reason is to avoid > > > increasing the packet length > > > > > > I appreciate further comments and would like more people review it > > > so that we can go ahead with this document. > > > > > > Thanks, > > > Hosnieh > > > > > > > > > > > > A new version of I-D, draft-rafiee-intarea-cga-tsig-07.txt > > > has been successfully submitted by Hosnieh Rafiee and posted to the > > > IETF repository. > > > > > > Name: draft-rafiee-intarea-cga-tsig > > > Revision: 07 > > > Title: Secure DNS Authentication using CGA/SSAS Algorithm > in IPv6 > > > Document date: 2014-02-15 > > > Group: Individual Submission > > > Pages: 26 > > > URL: > > > http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-07 > > > .t > > > xt > > > Status: > > > https://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/ > > > Htmlized: > http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-07 > > > Diff: > > > http://www.ietf.org/rfcdiff?url2=draft-rafiee-intarea-cga-tsig-07 > > > > > > Abstract: > > > This document describes a new mechanism that can be used to reduce > > > the need for human intervention during DNS authentication and secure > > > DNS authentication in various scenarios such as the DNS > > > authentication of resolvers to stub resolvers, authentication during > > > zone transfers, authentication of root DNS servers to recursive DNS > > > servers, and authentication during the FQDN (RFC 4703) update. > > > > > > Especially in the last scenario, i.e., FQDN, if the node uses the > > > Neighbor Discovery Protocol (NDP) (RFC 4861, RFC 4862), unlike the > > > Dynamic Host Configuration Protocol (DHCP) (RFC 3315), the node has > > > no way of updating his FQDN records on the DNS and has no means for a > > > secure authentication with the DNS server. While this is a major > > > problem in NDP-enabled networks, this is a minor problem in DHCPv6. > > > This is because the DHCP server updates the FQDN records on behalf of > > > the nodes on the network. This document also introduces a possible > > > algorithm for DNS data confidentiality. > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: dnsext [mailto:dnsext-bounces@ietf.org] On Behalf Of Marc > > >> Buijsman > > >> Sent: Thursday, January 16, 2014 3:45 PM > > >> To: dnsext@ietf.org > > >> Cc: Jeroen van der Ham > > >> Subject: [dnsext] CGA-TSIG research report > > >> > > >> Dear working group members, > > >> > > >> For my master's thesis I have performed an investigation at NLnet > > >> Labs on CGA-TSIG as a solution to the last mile problem of DNS. The > > >> version of the CGA-TSIG proposal that I reviewed is the current > > >> latest version at > > >> http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-06. During > > >> the > > > course of > > >> my research I have already had some contact with Ms. Rafiee. > > >> > > >> In order to do a verification of the CGA-TSIG proposal I have > > >> created a > > > proof > > >> of concept implementation in NLnet Labs' "ldns" library. Since the > > >> scope > > > of > > >> the project was limited to the last mile problem it only includes > > >> the code required for this purpose, but the implementation could > > >> easily be extended to support other applications (like zone > > >> transfers). I have found that > > > CGA-TSIG > > >> has potential to be an adequate solution to the last mile problem > > >> on > > >> IPv6 networks, although some future research is needed with regard > > >> to bootstrapping the authentication. > > >> > > >> As a result, I would hereby like to refer you to my report which > > >> can be > > > found > > >> at http://www.nlnetlabs.nl/downloads/publications/report-rp2- > > buijsman.pdf. > > >> I have outlined my results in section 4.2 which contains > > >> suggestions on > > > how I > > >> believe the CGA-TSIG draft could be clarified and otherwise improved. > > >> I > > > hope > > >> my suggestions will be adopted in the next version of the draft. > > >> The PoC > > > code > > >> can be found in the online Git repository of NLnet Labs at > > >> http://git.nlnetlabs.nl/ldns/?h=cga-tsig. > > >> > > >> I hope my work will be helpful in standardising CGA-TSIG. > > >> > > >> Yours sincerely, > > >> > > >> Marc Buijsman > > >> _______________________________________________ > > >> dnsext mailing list > > >> dnsext@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dnsext > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From nobody Sun Feb 16 05:02:06 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4581A01C7; Sun, 16 Feb 2014 05:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aVp5uV1hJQV; Sun, 16 Feb 2014 05:02:01 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 0723E1A002B; Sun, 16 Feb 2014 05:02:01 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 7C1C417BA76; Sun, 16 Feb 2014 14:01:58 +0100 (CET) Received: from [192.168.1.2] (178-84-162-64.dynamic.upc.nl [178.84.162.64]) by smtp.os3.nl (Postfix) with ESMTPSA id 5595D17BA75; Sun, 16 Feb 2014 14:01:58 +0100 (CET) Message-ID: <5300B6C6.8030903@os3.nl> Date: Sun, 16 Feb 2014 14:01:58 +0100 From: Marc Buijsman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hosnieh Rafiee References: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> <53009CFE.9030900@os3.nl> <003a01cf2b0c$067d2360$13776a20$@rozanak.com> <003b01cf2b10$091fbde0$1b5f39a0$@rozanak.com> In-Reply-To: <003b01cf2b10$091fbde0$1b5f39a0$@rozanak.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/SS4nq4yK0Zu-eW83CofFoeqCBDE Cc: 'Jeroen van der Ham' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] CGA-TSIG - new version X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 13:02:04 -0000 Dear Hosnieh, Let me first react to your first email of today. CGA uses the RSASSA-PKCS1-v1_5 signature algorithm to sign the message. The way I understand it as explained at http://tools.ietf.org/html/rfc3447#section-8.2.1 is that the length of the output signature S only depends on the length k of the RSA modulus n, and not on the length of the input message M. The algorithm accomplishes this by using a hash function on message M, SHA-1 in case of CGA. So provided that the RSA key has been determined, it does not matter how many fields you concatenate and take as input message M (although there is a maximum depending on the chosen hash function); the output will always be a signature of length k. The signature field is variable because the RSA key size is variable; not because the message is variable. I was not aware that SEND actually encodes groups of 8 bytes. I thought you meant that the value set in the length field should be a multiple of 8, but now I see you mean that the length of the data itself should be a multiple of 8. It is then logical that you might need padding to be able to make whole 'octobytes'. However, I don't believe that this padding is needed for the signature operation since the hash function takes a variable amount of input bytes anyway. You also didn't mention anything about padding in your draft (nor does the CGA RFC), so I assumed the encoded length to be in bytes just like the other length-encoding fields in the TSIG RR. I'm also not sure if you save more space by using 1 byte for the length-encoding field and additional padding, instead of 2 bytes for the length-encoding field without padding. Regarding the old signature, I think you could even leave out the timestamp from the old signature operation. As long as you sign the new public key with the old public key (with the old signature as ouput) in order to authenticate the new public key, it is also possible to authenticate the timestamp and fudge field provided that they have been signed with the new public key (as required by TSIG, which recommends a fudge value of 300 seconds i.e. 5 minutes, a bit more than a few seconds). Kind regards, Marc Buijsman Hosnieh Rafiee schreef op 16-2-2014 13:10: > Follow up, > > I thought again about the possible attacks scenarios. I concluded that I > also need to include the new public key in the content of the old signature. > This means the old signature should be "new public key + timestamp", > otherwise the attacker might have a possibility (a few seconds) to do the > replay attack by copying the old public key and oldsignature. So, you're > right, it still might cause the attacker to attack. But to avoid increasing > packet size, it is only enough for the two values that is new public key and > timestamp. Since the new public key is verified by both CGA verification > process and also the new signature and the old public key is verified by old > signature. > > I will correct this in the next version of the document. > > Thanks, > Best, > Hosnieh > > >> -----Original Message----- >> From: dnsext [mailto:dnsext-bounces@ietf.org] On Behalf Of Hosnieh Rafiee >> Sent: Sunday, February 16, 2014 12:41 PM >> To: 'Marc Buijsman' >> Cc: 'Jeroen van der Ham'; DNSOP@ietf.org; dnsext@ietf.org >> Subject: Re: [dnsext] CGA-TSIG - new version >> >> Dear Marc, >> >> Thanks for your comments. >> >>> Regarding the size of the length fields, however, I'm still confused >>> by >> what you >>> are trying to say. I did not consider the number of bits, I really >> considered the >>> number of bytes (octets). If I wanted to encode the length in bits >>> (and I >> don't), >>> I would have set the value to 2048. >>> But I'm dividing by 8 and set the value to 256 instead, which is the >> length in >>> *bytes* as you said yourself. The reason why you divide by 8 a second >>> time >> is >>> a mystery to me. The outcome would then be the number of groups of 8 >>> bytes, but I've never seen a length encoding before that counts such >>> 'octobytes' (which is not a byte, but 8 bytes). So you are counting 32 >>> octobytes, while I am counting 256 bytes (as usual). >> >>> Also, I don't understand what you mean to say by "multiple of 8". If >>> the encoding would be in bits (and again, it's not) and the data is >>> always a >> number >>> of whole bytes, then yes the value would be a multiple of 8. But we >>> are >> talking >>> about an encoding in bytes here, which do not necessarily come in >>> groups >> of >>> 8 (and is therefore not necessarily a multiple of 8). >>> I also don't know what checksum fields you mean or how their length is >>> relevant here, but the IPv4 header checksum field and UDP checksum >>> field >> in >>> a regular DNS packet are two bytes each. >> http://tools.ietf.org/html/rfc3971#section-5.1 >> maybe my wording is not correct. Check the length field here. 8 bits is > really >> not enough for that. So, If you check the implementation of SeNDs (Docomo, >> etc). what they do is they shift the values or easier way is to divide by > 8. >>> With regard to the old signature: how would including more fields in >>> the digest operation increase the packet size? No matter how many >>> fields you digest, the resulting signature is always of the same >>> length. And the >> fields I was >>> referring to are already part of the packet. In order to be able to >> authenticate >>> the new public key, you MUST at least include the new public key in >>> the >> digest >>> operation. Otherwise the packet could be intercepted and the new >>> public >> key >>> could be replaced without notice. >> You're not talking about SHA1 digest, you're talking about digital > signature. It >> depends on the input data. This is why , for example, in SeND they > included >> padding at the end that this value can be the multiple of 8. >> If this value had a fixed size, they would not include any length to it. > In RFCs >> they usually include lengths when the length of value is variable and > without >> length field, one cannot determine the length. >> http://tools.ietf.org/html/rfc3971#section-5.2 >> So, this value is not actually the same size and depends on the plain text > that >> one wants to sign. >> Secondly, if you check the content of the signature, you will notice that > I >> included all the DNS message and it is not like before. Because the new >> signature is verified before old signature, no replay attack can be > happened >> since the new signature verification will be failed. So no need to sign a > large >> data for old signature field and only timestamp or a small value is enough > just >> to show that this node is the owner of this public key. To avoid replay > attack >> again, I consider to sign the timestamp. >> >> I hope this answer your questions. >> >> >> Thanks, >> Best, >> Hosnieh >> >>> Kind regards, >>> >>> Marc Buijsman >>> >>> Hosnieh Rafiee schreef op 15-2-2014 0:07: >>>> Thanks for the information you've provided, I improved the document >>>> according to comments and found out that the report also has a few >>>> problems which is due to the fact that it misinterpreted the of >>>> CGA-TSIG >>> document. >>>> Here I explain the problems or the reasons of choices: >>>> >>>> - CGA-TSIG cannot use MAC as a signature field. The purpose was that >>>> to have all the CGA data in one section instead of trying to find >>>> them in different sections of TSIG. >>>> >>>> - sizes of length encoding: It is one byte. It is enough for any key >> sizes. >>>> If you also check the "checksum" field in the packets, you will find >>>> out that it is only 8 bits or one byte. In the emails I explained to >>>> you that it is the multiple of 8. In no RFC you can find out that >>>> the value is the length of data in bits. It is always the length of >>>> data in bytes. But how you showed in your report is that you >>>> consider the number of bits and not bytes so you had the following >>>> example >>>> 2048/8=256 (now you only converted the number of bits to bytes) so >>>> you needed to divide it by another 8 that is 256/8=32 and this is >>>> the value you set to length. If you even consider the key size 7680, >>>> then the length will be only 120. >>>> nd >>>> - old signature only contains time signed. The reason is to avoid >>>> increasing the packet length >>>> >>>> I appreciate further comments and would like more people review it >>>> so that we can go ahead with this document. >>>> >>>> Thanks, >>>> Hosnieh >>>> >>>> >>>> >>>> A new version of I-D, draft-rafiee-intarea-cga-tsig-07.txt >>>> has been successfully submitted by Hosnieh Rafiee and posted to the >>>> IETF repository. >>>> >>>> Name: draft-rafiee-intarea-cga-tsig >>>> Revision: 07 >>>> Title: Secure DNS Authentication using CGA/SSAS Algorithm >> in IPv6 >>>> Document date: 2014-02-15 >>>> Group: Individual Submission >>>> Pages: 26 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-07 >>>> .t >>>> xt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/ >>>> Htmlized: >> http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-07 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-rafiee-intarea-cga-tsig-07 >>>> >>>> Abstract: >>>> This document describes a new mechanism that can be used to reduce >>>> the need for human intervention during DNS authentication and > secure >>>> DNS authentication in various scenarios such as the DNS >>>> authentication of resolvers to stub resolvers, authentication > during >>>> zone transfers, authentication of root DNS servers to recursive DNS >>>> servers, and authentication during the FQDN (RFC 4703) update. >>>> >>>> Especially in the last scenario, i.e., FQDN, if the node uses the >>>> Neighbor Discovery Protocol (NDP) (RFC 4861, RFC 4862), unlike the >>>> Dynamic Host Configuration Protocol (DHCP) (RFC 3315), the node has >>>> no way of updating his FQDN records on the DNS and has no means for > a >>>> secure authentication with the DNS server. While this is a major >>>> problem in NDP-enabled networks, this is a minor problem in DHCPv6. >>>> This is because the DHCP server updates the FQDN records on behalf > of >>>> the nodes on the network. This document also introduces a possible >>>> algorithm for DNS data confidentiality. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: dnsext [mailto:dnsext-bounces@ietf.org] On Behalf Of Marc >>>>> Buijsman >>>>> Sent: Thursday, January 16, 2014 3:45 PM >>>>> To: dnsext@ietf.org >>>>> Cc: Jeroen van der Ham >>>>> Subject: [dnsext] CGA-TSIG research report >>>>> >>>>> Dear working group members, >>>>> >>>>> For my master's thesis I have performed an investigation at NLnet >>>>> Labs on CGA-TSIG as a solution to the last mile problem of DNS. The >>>>> version of the CGA-TSIG proposal that I reviewed is the current >>>>> latest version at >>>>> http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-06. During >>>>> the >>>> course of >>>>> my research I have already had some contact with Ms. Rafiee. >>>>> >>>>> In order to do a verification of the CGA-TSIG proposal I have >>>>> created a >>>> proof >>>>> of concept implementation in NLnet Labs' "ldns" library. Since the >>>>> scope >>>> of >>>>> the project was limited to the last mile problem it only includes >>>>> the code required for this purpose, but the implementation could >>>>> easily be extended to support other applications (like zone >>>>> transfers). I have found that >>>> CGA-TSIG >>>>> has potential to be an adequate solution to the last mile problem >>>>> on >>>>> IPv6 networks, although some future research is needed with regard >>>>> to bootstrapping the authentication. >>>>> >>>>> As a result, I would hereby like to refer you to my report which >>>>> can be >>>> found >>>>> at http://www.nlnetlabs.nl/downloads/publications/report-rp2- >>> buijsman.pdf. >>>>> I have outlined my results in section 4.2 which contains >>>>> suggestions on >>>> how I >>>>> believe the CGA-TSIG draft could be clarified and otherwise improved. >>>>> I >>>> hope >>>>> my suggestions will be adopted in the next version of the draft. >>>>> The PoC >>>> code >>>>> can be found in the online Git repository of NLnet Labs at >>>>> http://git.nlnetlabs.nl/ldns/?h=cga-tsig. >>>>> >>>>> I hope my work will be helpful in standardising CGA-TSIG. >>>>> >>>>> Yours sincerely, >>>>> >>>>> Marc Buijsman >>>>> _______________________________________________ >>>>> dnsext mailing list >>>>> dnsext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnsext >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext From nobody Sun Feb 16 06:51:32 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043581A0225; Sun, 16 Feb 2014 06:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maDieItrSixU; Sun, 16 Feb 2014 06:51:28 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 682F61A0238; Sun, 16 Feb 2014 06:51:28 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 476F823E2D48; Sun, 16 Feb 2014 14:51:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyYtgSZbJGyu; Sun, 16 Feb 2014 15:51:18 +0100 (CET) Received: from kopoli (g225015008.adsl.alicedsl.de [92.225.15.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 80A4F23E2B25; Sun, 16 Feb 2014 15:51:18 +0100 (CET) From: "Hosnieh Rafiee" To: "'Marc Buijsman'" References: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> <53009CFE.9030900@os3.nl> <003a01cf2b0c$067d2360$13776a20$@rozanak.com> <003b01cf2b10$091fbde0$1b5f39a0$@rozanak.com> <5300B6C6.8030903@os3.nl> In-Reply-To: <5300B6C6.8030903@os3.nl> Date: Sun, 16 Feb 2014 15:51:16 +0100 Message-ID: <005c01cf2b26$8b895aa0$a29c0fe0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQOKWVpFurMI2Qzh8V0RHyHseiUo8gI85gZYAcBsuHoCE4W3igGmux4JlwPGjTA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/dHxlnd8Kt9bfnxnrfqSsU6LzZ-8 Cc: 'Jeroen van der Ham' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] CGA-TSIG - new version X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 14:51:31 -0000 Dear Marc, Thanks again for your message. > Let me first react to your first email of today. CGA uses the > RSASSA-PKCS1-v1_5 signature algorithm to sign the message. The way I > understand it as explained at > http://tools.ietf.org/html/rfc3447#section-8.2.1 is that the length of the > output signature S only depends on the length k of the RSA modulus n, and > not on the length of the input message M. The algorithm accomplishes this by > using a hash function on message M, SHA-1 in case of CGA. So provided that > the RSA key has been determined, it does not matter how many fields you > concatenate and take as input message M (although there is a maximum > depending on the chosen hash function); the output will always be a signature > of length k. The signature field is variable because the RSA key size is variable; > not because the message is variable. You're right I guess I was confused two different things -- data encryption and signature generation. I re-checked the signature generation algorithm. Since first the data is hashed using SHA function and then the digest is encrypted using a private key, this will lead to having the same length signature. But I need to update the document that the signature should be generated based on the standard RSASSA-PKCS1-v1_5 or for ECC (as a future replacement of RSA) there should be a standard way. Because I think it is necessary to also consider other SHA algorithms since SHA1 is no longer consider a very strong hash function and CGA-TSIG needs to support any future changes to other algorithms. > I was not aware that SEND actually encodes groups of 8 bytes. I thought you > meant that the value set in the length field should be a multiple of 8, but now I > see you mean that the length of the data itself should be a multiple of 8. It is > then logical that you might need padding to be able to make whole > 'octobytes'. However, I don't believe that this padding is needed for the > signature operation since the hash function takes a variable amount of input > bytes anyway. You also didn't mention anything about padding in your draft > (nor does the CGA RFC), so I assumed the encoded length to be in bytes just > like the other length-encoding fields in the TSIG RR. I'm also not sure if you > save more space by using 1 byte for the length-encoding field and additional > padding, instead of 2 bytes for the length-encoding field without padding. IMHO, we do not really need two bytes and no padding is also needed. Because I think if the encryption is on hash function, then it always generates the same values that is multiple of 8. To have a proof of concept, I checked RSA signature a few minutes ago with different key sizes (1024bits , 1280bits, 1536bits, 1792bits,2048bits, 3072bits) and the result was always the multiple of 8. > Regarding the old signature, I think you could even leave out the timestamp > from the old signature operation. As long as you sign the new public key with > the old public key (with the old signature as ouput) in order to authenticate > the new public key, it is also possible to authenticate the timestamp and fudge > field provided that they have been signed with the new public key (as > required by TSIG, which recommends a fudge value of 300 seconds i.e. 5 > minutes, a bit more than a few seconds). Hum... I guess you're right. Signing only the new public key is enough and in this case no timestamp is needed for the old signature (not new signature). I know the attacker only has a small period of time to do this attack and if it cannot do it, since the new public key is replaced with the old one on the DNS server, it cannot do this attack anymore or this attack is not effective as there is no old public key anymore valid. So I assume this scenario can be like this: The original node wants to change its IP address or public key. It signs all DNS message excluding the signature fields using its own new private key and sign the new public key using its own old private key. Then submit this packet including the TSIG RR with CGA-TSIG DATA The attacker eavesdrops and copy only the old public key and old signature from the packet and sign the DNS message using its own private key and submit this value... But the verification of the old signature fails since the attacker cannot copy the new public key of the original node. If it does this, the CGA verification will be failed and the node cannot prove the owner of this public key. So, By assuming such failure in the attack scenario. I guess only signing the new public key for old signature is enough. For this purpose no more authentication is needed since the time has been already checked for the new signature. Thanks, Best, Hosnieh From nobody Sun Feb 16 12:09:17 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AC71A027D; Sun, 16 Feb 2014 12:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkdmOHm__2FF; Sun, 16 Feb 2014 12:09:12 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id B875F1A0208; Sun, 16 Feb 2014 12:09:11 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [145.100.96.119]) by mail.serv.os3.nl (Postfix) with ESMTP id CE43917B5D1; Sun, 16 Feb 2014 21:09:07 +0100 (CET) Received: from [192.168.1.2] (178-84-162-64.dynamic.upc.nl [178.84.162.64]) by smtp.os3.nl (Postfix) with ESMTPSA id 9924E17B5BB; Sun, 16 Feb 2014 21:09:07 +0100 (CET) Message-ID: <53011AE3.20102@os3.nl> Date: Sun, 16 Feb 2014 21:09:07 +0100 From: Marc Buijsman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hosnieh Rafiee References: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> <53009CFE.9030900@os3.nl> <003a01cf2b0c$067d2360$13776a20$@rozanak.com> <003b01cf2b10$091fbde0$1b5f39a0$@rozanak.com> <5300B6C6.8030903@os3.nl> <005c01cf2b26$8b895aa0$a29c0fe0$@rozanak.com> In-Reply-To: <005c01cf2b26$8b895aa0$a29c0fe0$@rozanak.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/y0oqMpHZQW3kv8xXSAd6JqfUPvU Cc: 'Jeroen van der Ham' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] CGA-TSIG - new version X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 20:09:14 -0000 Dear Hosnieh, > You're right I guess I was confused two different things -- data encryption > and signature generation. I re-checked the signature generation algorithm. > Since first the data is hashed using SHA function and then the digest is > encrypted using a private key, this will lead to having the same length > signature. I'm glad you agree. :) > But I need to update the document that the signature should be generated > based on the standard RSASSA-PKCS1-v1_5 or for ECC (as a future replacement > of RSA) there should be a standard way. Because I think it is necessary to > also consider other SHA algorithms since SHA1 is no longer consider a very > strong hash function and CGA-TSIG needs to support any future changes to > other algorithms. Yes, that's what I thought too, so that's why I proposed to use 1.2.840.113549.1.1.5 (note the last 5 instead of 1) for RSA+SHA1. > IMHO, we do not really need two bytes and no padding is also needed. Because > I think if the encryption is on hash function, then it always generates the > same values that is multiple of 8. To have a proof of concept, I checked RSA > signature a few minutes ago with different key sizes (1024bits , 1280bits, > 1536bits, 1792bits,2048bits, 3072bits) and the result was always the > multiple of 8. This is indeed true for the signature fields. However, you also defined single-byte length fields for the complete CGA-TSIG DATA field, the Parameters field and the Old PK field (not in the table in section 4.1 of draft 07, but you do in the figure in section 4.2). The Parameters field includes the public key, which consists of (for example) an 1024-bit modulus, but also of a variably sized exponent (say 3 bytes), PLUS the bytes of the encapsulating DER encoding. According to my calculations, this requires a minimum of 161 bytes for the complete DER-encoded public key. If you then add the 16-byte modifier, the 8-byte prefix, the 1-byte collision count, and 0 bytes for the extension fields (but this one is variable as well), then you get a total size of 186 for the Parameters field, which is not a multiple of 8. You would then need 6 bytes of additional padding, or fiddle with the padding inside the DER structure (but I don't think this is desirable). Assuming that the Old PK is also a DER-encoded ASN.1 structure and that an Old PK of similar size is added to the packet (161 + 7 bytes padding), then the complete CGA-TSIG DATA field would be of size 660 (including 22 bytes for the encoding of 1.2.840.113549.1.1.5 in domain name syntax and two signatures of length 128), which requires an additional padding of 4 bytes to make it a multiple of 8. So the total padding in this case would be 6 + 7 + 4 = 17 bytes. However, if you would use 2 bytes for all five length fields then you don't need padding and you would actually spare 17 - 5 = 12 bytes. To be honest, I don't think the difference is significant enough with respect to the total size of 664 bytes to make it a strong argument for using 2-byte length fields, but I do think that it makes implementing CGA-TSIG much more straightforward without having the hassle of adding paddings to each variably sized field. It would also be in line with the size of the length fields defined by TSIG, which are also 2 bytes. > Hum... I guess you're right. Signing only the new public key is enough and > in this case no timestamp is needed for the old signature (not new > signature). I know the attacker only has a small period of time to do this > attack and if it cannot do it, since the new public key is replaced with the > old one on the DNS server, it cannot do this attack anymore or this attack > is not effective as there is no old public key anymore valid. > So I assume this scenario can be like this: > The original node wants to change its IP address or public key. It signs all > DNS message excluding the signature fields using its own new private key and > sign the new public key using its own old private key. Then submit this > packet including the TSIG RR with CGA-TSIG DATA > > The attacker eavesdrops and copy only the old public key and old signature > from the packet and sign the DNS message using its own private key and > submit this value... But the verification of the old signature fails since > the attacker cannot copy the new public key of the original node. If it does > this, the CGA verification will be failed and the node cannot prove the > owner of this public key. > > So, > By assuming such failure in the attack scenario. I guess only signing the > new public key for old signature is enough. For this purpose no more > authentication is needed since the time has been already checked for the new > signature. Agreed. That only leaves the problem of how you notify your clients of your new IPv6 address. :) Thank you! Kind regards, Marc Buijsman From nobody Sun Feb 16 13:11:34 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D824C1A041B; Sun, 16 Feb 2014 13:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN0evIwLRFyv; Sun, 16 Feb 2014 13:11:25 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7F41A02E5; Sun, 16 Feb 2014 13:11:25 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 7DDC223E2D48; Sun, 16 Feb 2014 21:11:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mngg6NlyLpWw; Sun, 16 Feb 2014 22:11:20 +0100 (CET) Received: from kopoli (g225015008.adsl.alicedsl.de [92.225.15.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 1A2B923E2B25; Sun, 16 Feb 2014 22:11:20 +0100 (CET) From: "Hosnieh Rafiee" To: "'Marc Buijsman'" References: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> <53009CFE.9030900@os3.nl> <003a01cf2b0c$067d2360$13776a20$@rozanak.com> <003b01cf2b10$091fbde0$1b5f39a0$@rozanak.com> <5300B6C6.8030903@os3.nl> <005c01cf2b26$8b895aa0$a29c0fe0$@rozanak.com> <53011AE3.20102@os3.nl> In-Reply-To: <53011AE3.20102@os3.nl> Date: Sun, 16 Feb 2014 22:11:17 +0100 Message-ID: <000f01cf2b5b$a26b6800$e7423800$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQOKWVpFurMI2Qzh8V0RHyHseiUo8gI85gZYAcBsuHoCE4W3igGmux4JAfAtHs4C/eRXQpbc0RYg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/yKSE707mQG_CFgSiEXBJEpclxqw Cc: 'Jeroen van der Ham' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] CGA-TSIG - new version X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 21:11:30 -0000 Dear Marc, > Yes, that's what I thought too, so that's why I proposed to use > 1.2.840.113549.1.1.5 (note the last 5 instead of 1) for RSA+SHA1. > > > IMHO, we do not really need two bytes and no padding is also needed. > > Because I think if the encryption is on hash function, then it always > > generates the same values that is multiple of 8. To have a proof of > > concept, I checked RSA signature a few minutes ago with different key > > sizes (1024bits , 1280bits, 1536bits, 1792bits,2048bits, 3072bits) and > > the result was always the multiple of 8. > > This is indeed true for the signature fields. However, you also defined single- > byte length fields for the complete CGA-TSIG DATA field, the Parameters field > and the Old PK field (not in the table in section 4.1 of draft 07, but you do in > the figure in section 4.2). The Parameters field includes the public key, which > consists of (for example) an 1024-bit modulus, but also of a variably sized > exponent (say 3 bytes), PLUS the bytes of the encapsulating DER encoding. > According to my calculations, this requires a minimum of 161 bytes for the > complete DER-encoded public key. If you then add the 16-byte modifier, the > 8-byte prefix, the 1-byte collision count, and 0 bytes for the extension fields > (but this one is variable as well), then you get a total size of 186 for the > Parameters field, which is not a multiple of 8. You would then need > 6 bytes of additional padding, or fiddle with the padding inside the DER > structure (but I don't think this is desirable). > > Assuming that the Old PK is also a DER-encoded ASN.1 structure and that an > Old PK of similar size is added to the packet (161 + 7 bytes padding), then the > complete CGA-TSIG DATA field would be of size 660 (including 22 bytes for > the encoding of 1.2.840.113549.1.1.5 in domain name syntax and two > signatures of length 128), which requires an additional padding of 4 bytes to > make it a multiple of 8. > So the total padding in this case would be 6 + 7 + 4 = 17 bytes. > However, if you would use 2 bytes for all five length fields then you don't > need padding and you would actually spare 17 - 5 = 12 bytes. To be honest, I > don't think the difference is significant enough with respect to the total size of > 664 bytes to make it a strong argument for using 2-byte length fields, but I do > think that it makes implementing CGA-TSIG much more straightforward > without having the hassle of adding paddings to each variably sized field. It > would also be in line with the size of the length fields defined by TSIG, which > are also 2 bytes. Agreed. For CGA-TSIG data structure, I will change it but for signatures, I will let it to be only 8 bits since it does not need it. > Agreed. That only leaves the problem of how you notify your clients of your > new IPv6 address. :) It is also not a problem. I addressed it in the new version. The client receives the IP address of the DNS server from the option of the router advertisement (if it wants to be secure) and this is the recommended way. So, the routers usually sends the RA message in a frequent intervals. This also inform the clients about any changes of the DNS information such as the DNS IP addresses. I just explain a possible attack scenario here A node receives a RA message and after verification accepts that router prefix and also sets its DNS IP address (resolver A). Whenever it wants to resolve any domain names, it asks the resolver A to translate a domain to an iP address. Now consider a case where resolver A changes its IP address for whatever reason. If we say that the RA message interval is 10 minutes. The node now wants to resolve a name and since it hasn't yet received any new RA message, it sends a message to the old resolver. We assume that the attacker can eavesdrop this message. He immediately answers instead of legitimate resolver (since there is no resolver using that old IP address). The resolver, according to CGA-TSIG document, needs to include the CGA-TSIG data structure that enables the other nodes to verify it. Since the attacker does not have the private key of the legitimate resolver, it cannot spoof the old IP address of the legitimate resolver since the CGA verification will fails and signature is not valid if the time signed is an old time. So, this attack fails. But only the problem is that the node needs to either wait for another RA message to receive the new information about the resolver or can send a RS message and ask for a new RA message to save time. This can happen after the node does not receive any response from the legitimate resolver. It then assumes that the legitimate resolver is not alive anymore. The other way to solve this problem is that. The resolver announce the nodes who wants to communicate, about the changes in its IP address. But this is more complicated than the first solution. Because, the node should know when the resolver wants to change its IP address. However, we can decrease the complexity by having a default standard value. Say something like 10 minutes. So, if the resolver receives any query request 10 minutes before changing its IP address, it will include the its old IP address as mentioned in CGA-TSIG document. This inform the nodes that the resolver's old IP address will not be valid after 10 minutes and they need to replace this IP for further communication in their cache. The last solution would be using both approach to ensure the client can translate the names to IP without any delay to go through sending RS and receiving RA, etc. Thanks, Best, Hosnieh From nobody Mon Feb 24 12:33:24 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144821A0202; Mon, 24 Feb 2014 12:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1TsaGAWGo1l; Mon, 24 Feb 2014 12:33:15 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 585CB1A02E1; Mon, 24 Feb 2014 12:33:15 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id C143E23E2D51; Mon, 24 Feb 2014 20:33:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF-RQx93clJU; Mon, 24 Feb 2014 21:33:09 +0100 (CET) Received: from kopoli (g225058231.adsl.alicedsl.de [92.225.58.231]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id EF72523E24C1; Mon, 24 Feb 2014 21:33:08 +0100 (CET) From: "Hosnieh Rafiee" To: "'Marc Buijsman'" References: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> <53009CFE.9030900@os3.nl> <003a01cf2b0c$067d2360$13776a20$@rozanak.com> <003b01cf2b10$091fbde0$1b5f39a0$@rozanak.com> <5300B6C6.8030903@os3.nl> <005c01cf2b26$8b895aa0$a29c0fe0$@rozanak.com> <53011AE3.20102@os3.nl> <000f01cf2b5b$a26b6800$e7423800$@rozanak.com> In-Reply-To: <000f01cf2b5b$a26b6800$e7423800$@rozanak.com> Date: Mon, 24 Feb 2014 21:33:03 +0100 Message-ID: <00ba01cf319f$a10e6530$e32b2f90$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQOKWVpFurMI2Qzh8V0RHyHseiUo8gI85gZYAcBsuHoCE4W3igGmux4JAfAtHs4C/eRXQgH21IMfltmoiXA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/CXc3gx5mFSL-_xtIkZ11Vu6TAaE Cc: 'Jeroen van der Ham' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] CGA-TSIG - new version X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 20:33:20 -0000 Dear Marc, Do you have any other comments or I could address your concerns? Thanks, Best, Hosnieh > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Hosnieh Rafiee > Sent: Sunday, February 16, 2014 10:11 PM > To: 'Marc Buijsman' > Cc: 'Jeroen van der Ham'; DNSOP@ietf.org; dnsext@ietf.org > Subject: Re: [DNSOP] [dnsext] CGA-TSIG - new version > > Dear Marc, > > > > Yes, that's what I thought too, so that's why I proposed to use > > 1.2.840.113549.1.1.5 (note the last 5 instead of 1) for RSA+SHA1. > > > > > IMHO, we do not really need two bytes and no padding is also needed. > > > Because I think if the encryption is on hash function, then it > > > always generates the same values that is multiple of 8. To have a > > > proof of concept, I checked RSA signature a few minutes ago with > > > different key sizes (1024bits , 1280bits, 1536bits, > > > 1792bits,2048bits, 3072bits) and the result was always the multiple of 8. > > > > This is indeed true for the signature fields. However, you also > > defined > single- > > byte length fields for the complete CGA-TSIG DATA field, the > > Parameters > field > > and the Old PK field (not in the table in section 4.1 of draft 07, but > > you > do in > > the figure in section 4.2). The Parameters field includes the public > > key, > which > > consists of (for example) an 1024-bit modulus, but also of a variably > sized > > exponent (say 3 bytes), PLUS the bytes of the encapsulating DER encoding. > > According to my calculations, this requires a minimum of 161 bytes for > > the complete DER-encoded public key. If you then add the 16-byte > > modifier, the 8-byte prefix, the 1-byte collision count, and 0 bytes > > for the extension > fields > > (but this one is variable as well), then you get a total size of 186 > > for > the > > Parameters field, which is not a multiple of 8. You would then need > > 6 bytes of additional padding, or fiddle with the padding inside the > > DER structure (but I don't think this is desirable). > > > > Assuming that the Old PK is also a DER-encoded ASN.1 structure and > > that an Old PK of similar size is added to the packet (161 + 7 bytes > > padding), > then the > > complete CGA-TSIG DATA field would be of size 660 (including 22 bytes > > for the encoding of 1.2.840.113549.1.1.5 in domain name syntax and two > > signatures of length 128), which requires an additional padding of 4 > > bytes > to > > make it a multiple of 8. > > > So the total padding in this case would be 6 + 7 + 4 = 17 bytes. > > However, if you would use 2 bytes for all five length fields then you > don't > > need padding and you would actually spare 17 - 5 = 12 bytes. To be > > honest, > I > > don't think the difference is significant enough with respect to the > > total > size of > > 664 bytes to make it a strong argument for using 2-byte length fields, > > but > I do > > think that it makes implementing CGA-TSIG much more straightforward > > without having the hassle of adding paddings to each variably sized field. > It > > would also be in line with the size of the length fields defined by > > TSIG, > which > > are also 2 bytes. > > > Agreed. For CGA-TSIG data structure, I will change it but for signatures, I will > let it to be only 8 bits since it does not need it. > > > > Agreed. That only leaves the problem of how you notify your clients of > your > > new IPv6 address. :) > > It is also not a problem. I addressed it in the new version. The client receives > the IP address of the DNS server from the option of the router advertisement > (if it wants to be secure) and this is the recommended way. > So, the routers usually sends the RA message in a frequent intervals. This also > inform the clients about any changes of the DNS information such as the DNS > IP addresses. > > I just explain a possible attack scenario here > > A node receives a RA message and after verification accepts that router prefix > and also sets its DNS IP address (resolver A). Whenever it wants to resolve any > domain names, it asks the resolver A to translate a domain to an iP address. > > Now consider a case where resolver A changes its IP address for whatever > reason. If we say that the RA message interval is 10 minutes. The node now > wants to resolve a name and since it hasn't yet received any new RA message, > it sends a message to the old resolver. We assume that the attacker can > eavesdrop this message. He immediately answers instead of legitimate > resolver (since there is no resolver using that old IP address). The resolver, > according to CGA-TSIG document, needs to include the CGA-TSIG data > structure that enables the other nodes to verify it. Since the attacker does not > have the private key of the legitimate resolver, it cannot spoof the old IP > address of the legitimate resolver since the CGA verification will fails and > signature is not valid if the time signed is an old time. So, this attack fails. But > only the problem is that the node needs to either wait for another RA > message to receive the new information about the resolver or can send a RS > message and ask for a new RA message to save time. This can happen after the > node does not receive any response from the legitimate resolver. > It then assumes that the legitimate resolver is not alive anymore. > > The other way to solve this problem is that. The resolver announce the nodes > who wants to communicate, about the changes in its IP address. But this is > more complicated than the first solution. Because, the node should know > when the resolver wants to change its IP address. However, we can decrease > the complexity by having a default standard value. Say something like 10 > minutes. So, if the resolver receives any query request 10 minutes before > changing its IP address, it will include the its old IP address as mentioned in > CGA-TSIG document. This inform the nodes that the resolver's old IP address > will not be valid after 10 minutes and they need to replace this IP for further > communication in their cache. > > The last solution would be using both approach to ensure the client can > translate the names to IP without any delay to go through sending RS and > receiving RA, etc. > > Thanks, > Best, > Hosnieh > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Feb 24 13:37:31 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D931A0277; Mon, 24 Feb 2014 13:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpxRu-q3U5YC; Mon, 24 Feb 2014 13:37:25 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 56EF01A0193; Mon, 24 Feb 2014 13:37:25 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 3C60617B81A; Mon, 24 Feb 2014 22:37:23 +0100 (CET) Received: from [192.168.1.2] (178-84-162-64.dynamic.upc.nl [178.84.162.64]) by smtp.os3.nl (Postfix) with ESMTPSA id 01F4617B7AE; Mon, 24 Feb 2014 22:37:22 +0100 (CET) Message-ID: <530BBB92.7010001@os3.nl> Date: Mon, 24 Feb 2014 22:37:22 +0100 From: Marc Buijsman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hosnieh Rafiee References: <021201cf29d9$8a5daa30$9f18fe90$@rozanak.com> <53009CFE.9030900@os3.nl> <003a01cf2b0c$067d2360$13776a20$@rozanak.com> <003b01cf2b10$091fbde0$1b5f39a0$@rozanak.com> <5300B6C6.8030903@os3.nl> <005c01cf2b26$8b895aa0$a29c0fe0$@rozanak.com> <53011AE3.20102@os3.nl> <000f01cf2b5b$a26b6800$e7423800$@rozanak.com> <00ba01cf319f$a10e6530$e32b2f90$@rozanak.com> In-Reply-To: <00ba01cf319f$a10e6530$e32b2f90$@rozanak.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/-vMQhZCjcoyfxejSHPtKVVypcNs Cc: 'Jeroen van der Ham' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] CGA-TSIG - new version X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 21:37:29 -0000 Dear Hosnieh, I have no further comments at the moment. I did not have the chance to completely read the new version so I was not aware of Section 10, but I like that you addressed it! Overall, it is nice to see that the draft has been improved. I hope others will have a look at it and help improve it more in order to go forward. Thanks for thinking along with me, I appreciate it! Best regards, Marc Buijsman Hosnieh Rafiee schreef op 24-2-2014 21:33: > Dear Marc, > Do you have any other comments or I could address your concerns? > > Thanks, > > Best, > Hosnieh > >> -----Original Message----- >> From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Hosnieh Rafiee >> Sent: Sunday, February 16, 2014 10:11 PM >> To: 'Marc Buijsman' >> Cc: 'Jeroen van der Ham'; DNSOP@ietf.org; dnsext@ietf.org >> Subject: Re: [DNSOP] [dnsext] CGA-TSIG - new version >> >> Dear Marc, >> >> >>> Yes, that's what I thought too, so that's why I proposed to use >>> 1.2.840.113549.1.1.5 (note the last 5 instead of 1) for RSA+SHA1. >>> >>>> IMHO, we do not really need two bytes and no padding is also needed. >>>> Because I think if the encryption is on hash function, then it >>>> always generates the same values that is multiple of 8. To have a >>>> proof of concept, I checked RSA signature a few minutes ago with >>>> different key sizes (1024bits , 1280bits, 1536bits, >>>> 1792bits,2048bits, 3072bits) and the result was always the multiple of > 8. >>> This is indeed true for the signature fields. However, you also >>> defined >> single- >>> byte length fields for the complete CGA-TSIG DATA field, the >>> Parameters >> field >>> and the Old PK field (not in the table in section 4.1 of draft 07, but >>> you >> do in >>> the figure in section 4.2). The Parameters field includes the public >>> key, >> which >>> consists of (for example) an 1024-bit modulus, but also of a variably >> sized >>> exponent (say 3 bytes), PLUS the bytes of the encapsulating DER > encoding. >>> According to my calculations, this requires a minimum of 161 bytes for >>> the complete DER-encoded public key. If you then add the 16-byte >>> modifier, the 8-byte prefix, the 1-byte collision count, and 0 bytes >>> for the extension >> fields >>> (but this one is variable as well), then you get a total size of 186 >>> for >> the >>> Parameters field, which is not a multiple of 8. You would then need >>> 6 bytes of additional padding, or fiddle with the padding inside the >>> DER structure (but I don't think this is desirable). >>> >>> Assuming that the Old PK is also a DER-encoded ASN.1 structure and >>> that an Old PK of similar size is added to the packet (161 + 7 bytes >>> padding), >> then the >>> complete CGA-TSIG DATA field would be of size 660 (including 22 bytes >>> for the encoding of 1.2.840.113549.1.1.5 in domain name syntax and two >>> signatures of length 128), which requires an additional padding of 4 >>> bytes >> to >>> make it a multiple of 8. >>> So the total padding in this case would be 6 + 7 + 4 = 17 bytes. >>> However, if you would use 2 bytes for all five length fields then you >> don't >>> need padding and you would actually spare 17 - 5 = 12 bytes. To be >>> honest, >> I >>> don't think the difference is significant enough with respect to the >>> total >> size of >>> 664 bytes to make it a strong argument for using 2-byte length fields, >>> but >> I do >>> think that it makes implementing CGA-TSIG much more straightforward >>> without having the hassle of adding paddings to each variably sized > field. >> It >>> would also be in line with the size of the length fields defined by >>> TSIG, >> which >>> are also 2 bytes. >> >> Agreed. For CGA-TSIG data structure, I will change it but for signatures, > I will >> let it to be only 8 bits since it does not need it. >> >> >>> Agreed. That only leaves the problem of how you notify your clients of >> your >>> new IPv6 address. :) >> It is also not a problem. I addressed it in the new version. The client > receives >> the IP address of the DNS server from the option of the router > advertisement >> (if it wants to be secure) and this is the recommended way. >> So, the routers usually sends the RA message in a frequent intervals. This > also >> inform the clients about any changes of the DNS information such as the > DNS >> IP addresses. >> >> I just explain a possible attack scenario here >> >> A node receives a RA message and after verification accepts that router > prefix >> and also sets its DNS IP address (resolver A). Whenever it wants to > resolve any >> domain names, it asks the resolver A to translate a domain to an iP > address. >> Now consider a case where resolver A changes its IP address for whatever >> reason. If we say that the RA message interval is 10 minutes. The node now >> wants to resolve a name and since it hasn't yet received any new RA > message, >> it sends a message to the old resolver. We assume that the attacker can >> eavesdrop this message. He immediately answers instead of legitimate >> resolver (since there is no resolver using that old IP address). The > resolver, >> according to CGA-TSIG document, needs to include the CGA-TSIG data >> structure that enables the other nodes to verify it. Since the attacker > does not >> have the private key of the legitimate resolver, it cannot spoof the old > IP >> address of the legitimate resolver since the CGA verification will fails > and >> signature is not valid if the time signed is an old time. So, this attack > fails. But >> only the problem is that the node needs to either wait for another RA >> message to receive the new information about the resolver or can send a RS >> message and ask for a new RA message to save time. This can happen after > the >> node does not receive any response from the legitimate resolver. >> It then assumes that the legitimate resolver is not alive anymore. >> >> The other way to solve this problem is that. The resolver announce the > nodes >> who wants to communicate, about the changes in its IP address. But this is >> more complicated than the first solution. Because, the node should know >> when the resolver wants to change its IP address. However, we can decrease >> the complexity by having a default standard value. Say something like 10 >> minutes. So, if the resolver receives any query request 10 minutes before >> changing its IP address, it will include the its old IP address as > mentioned in >> CGA-TSIG document. This inform the nodes that the resolver's old IP > address >> will not be valid after 10 minutes and they need to replace this IP for > further >> communication in their cache. >> >> The last solution would be using both approach to ensure the client can >> translate the names to IP without any delay to go through sending RS and >> receiving RA, etc. >> >> Thanks, >> Best, >> Hosnieh >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri Feb 28 06:55:35 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B461A07B5; Fri, 28 Feb 2014 06:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FS_WE_WANT=1.629, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImCaNTGse3ep; Fri, 28 Feb 2014 06:55:29 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 12DB31A01E8; Fri, 28 Feb 2014 06:55:29 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 7491523E2D51; Fri, 28 Feb 2014 14:55:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyS8AdK2ueB2; Fri, 28 Feb 2014 15:55:23 +0100 (CET) Received: from kopoli (g225115060.adsl.alicedsl.de [92.225.115.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 5F1F123E24C1; Fri, 28 Feb 2014 15:55:23 +0100 (CET) From: "Hosnieh Rafiee" To: , Date: Fri, 28 Feb 2014 15:55:21 +0100 Message-ID: <002101cf3495$1ad2d570$50788050$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac80lRjPs+oEPGR+Qe6rhNpf40faRg== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/sPy6eQuCb3R7Gn8Yr1OQuyHq8tg Subject: [dnsext] We want to have fruitful discussions - please review X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 14:55:31 -0000 Dear All, Since we have a timeslot to present http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig in DNSOP. I ask you please review it so that the discussion would be fruitful and we can receive good comments to improve it and to move ahead. This draft is not a new one as many of you already know or heard about it, it was first presented in IETF 85 and recently in IETF 88 in Int-area. The reason was because it was more related to DNSEXT and at that time it was going to shut down. It had several volunteer reviewers and it received some good comments. However, we would like to receive more comments in case we missed anything that needs to be addressed or we missed to clarify any section in the draft that needs more clarifications. Since now the DNS confidentiality is also an important topic and this proposal could handle it for IPv6 and during data transfer, I also included a section and explained the required changes to the original proposal. Here again I briefly explain the purpose of this document for those who do not know about it or who do not know the exact purpose of it: This proposal is for the cases where DNS uses IPv6 and there is a need to use a security mechanism for DNS authentication or provide the data confidentiality for the DNS data during transferring data over the network. It is possible to use this proposal in different DNS scenarios such as DNS update, updating FQDN and PTR, or DNS resolving. In this case it is enough that the verifier node only knows the IP address of the DNS server or resolver. For DNS update, this IP address can be set manually for the first time in the DNS configuration file and for other times, the CGA-TSIG can handle the changes with the proposed specifications. For DNS resolver, it receives this IP address securely via the option in the router advertisement message. The implementation of this part is also available. one need to use a suitable solution for secure authentication purposes while at the same time decrease the human intervention for the configuration. CGA-TSIG is the combination of the use of SSAS or CGA as an authentication purpose for DNS protocol and TSIG. SSAS/CGA is the mechanism which provides the node with the proof of IP address ownership by finding a binding between the IP address and the nodes' public key. Since this approach prevent IP spoofing (in network layer), it also ensures the DNS server or the clients that the one who is talking with is the owner of this IP address without the need to check the public key to the root to find out that this public key is really belong to this node with this IP address. So, using this approach can eliminate the need for this check. It can be also integrated with DNSSEC for this purpose and prevent IP spoofing without the need to check the keys up to the root level and simplify the key exchange process. This proposal also can be helpful for resolving scenario that is now a problem. Since for DNSSEC, exchanging the key of the resolver is the problem because the resolver must answer to anonymous queries, it is not easy to exchange the keys of this DNSSEC resolver to all the nodes who wants to ask this resolver. But with using this approach as I explained earlier, the IP address of the resolver can be obtained in a secure manner via the RA message and then since there is a binding between the IP address and the public key, the CGA/SSAS verification helps to verify this resolver. There is a recent discussion about privacy and data confidentiality. This proposal can also handle data confidentiality during the data exchanged between two nodes (servers or clients). Since the node knows the IP address of the DNS server, it can ask the DNS server to send the node, its public key. Then the node can encrypt a secret key with this public key and then encrypt the whole message using this secret key and AES or other symmetric algorithms. The DNS server then decrypt the secret key with its own private key and decrypt the whole DNS message by using this secret key. This provides the data confidentiality during DNS updates or also it can be used during DNS resolving. (if necessary) If you don't know anything about CGA, I try to explain it in a very simple example: Note that all values are in hexadecimal CGA parameters= e387d788a9e529701ba9baf0bb3694de20051abcab8c7dc000e581e41c6891dd5c06fee6f3ab 149bcf00d18d90534606354b8b8d7511ff90552393f974082732f16b646a97d336190c26d5e1 0347422ebfd6da4036d1e363f9de5c85091448b330ca8b541d246c378de29e9f37b19c072974 2d0a04ac0befe2e5069dd16cea03762b6d621d5d15fbf00131a5ee48f91d5a46396af46d01e6 17010001 Sha1(CGA parameters) = e584448d597e3c927805fc18250598a1d1b71b46 now set bits u and g and sec value so only the first bytes will change CGA value= 2784448d Thank you and looking forward to see you all in our talk. Since I cannot make it and will not be in London, Erik will present in my place but can answer some questions and I will also follow it in jabber. I hope to see a fruitful conversations :-) -----------smile---------- Hosnieh From nobody Fri Feb 28 07:03:31 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC201A02BD; Fri, 28 Feb 2014 07:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq-_6W6i67Yz; Fri, 28 Feb 2014 07:03:25 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id B9E0C1A01E8; Fri, 28 Feb 2014 07:03:25 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 7EE8623E2D51; Fri, 28 Feb 2014 15:03:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSnSx-mj_aw2; Fri, 28 Feb 2014 16:03:22 +0100 (CET) Received: from kopoli (g225115060.adsl.alicedsl.de [92.225.115.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id EE16E23E24C1; Fri, 28 Feb 2014 16:03:21 +0100 (CET) From: "Hosnieh Rafiee" To: , Date: Fri, 28 Feb 2014 16:03:20 +0100 Message-ID: <002e01cf3496$3815b840$a84128c0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac80ljcq+IFdQYqNRCGC533InN3wjw== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/XdcDx7kFF9iZn4JNCEyIXU7g-Kg Subject: [dnsext] followup - We want to have fruitful discussions - please review X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 15:03:27 -0000 Followup: I forgot to mention that what are CGA parameters (that is really important) The most important parameter is public key. So CGA uses the hash of public key and after some conditions and settings, set the CGA value as a 64 rightmost bits of an IPv6 address IIPv6= Subnetprefix + cga value So, this makes a binding between the IP address and the public key. > If you don't know anything about CGA, I try to explain it in a very simple > example: > > Note that all values are in hexadecimal > > CGA parameters= > e387d788a9e529701ba9baf0bb3694de20051abcab8c7dc000e581e41c689 > 1dd5c06fee6f3ab > 149bcf00d18d90534606354b8b8d7511ff90552393f974082732f16b646a97 > d336190c26d5e1 > 0347422ebfd6da4036d1e363f9de5c85091448b330ca8b541d246c378de29 > e9f37b19c072974 > 2d0a04ac0befe2e5069dd16cea03762b6d621d5d15fbf00131a5ee48f91d5a > 46396af46d01e6 > 17010001 > > > Sha1(CGA parameters) = e584448d597e3c927805fc18250598a1d1b71b46 > now set bits u and g and sec value so only the first bytes will change > > CGA value= 2784448d > > Thank you and looking forward to see you all in our talk. Since I cannot > make it and will not be in London, Erik will present in my place but can > answer some questions and I will also follow it in jabber. I hope to see a > fruitful conversations :-) >