Re: [DNSOP] [dnsext] CGA-TSIG - new version

"Hosnieh Rafiee" <ietf@rozanak.com> Fri, 14 February 2014 23:07 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@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" <ietf@rozanak.com>
To: <dnsext@ietf.org>, <DNSOP@ietf.org>
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/dnsop/TF4Ysd2qn1vdHlyrVg5hYtNKEeQ
Cc: 'Jeroen van der Ham' <vdham@uva.nl>, 'Marc Buijsman' <Marc.Buijsman@os3.nl>
Subject: Re: [DNSOP] [dnsext] CGA-TSIG - new version
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 23:07:46 -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