Re: [DNSOP] [dnsext] draft-rafiee-intarea-cga-tsig-07 -

"Hosnieh Rafiee" <ietf@rozanak.com> Sat, 15 February 2014 20:16 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 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 <ietf@rozanak.com>
To: dnsext@ietf.org, DNSOP@ietf.org
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/dnsop/r3KcEMslSLm6vxjZFGhR-HhqDSc
Subject: Re: [DNSOP] [dnsext] draft-rafiee-intarea-cga-tsig-07 -
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: 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.
> 
> 
>