Re: [dnsext] Extending UPDATE to add/remove zones

"Hosnieh Rafiee" <ietf@rozanak.com> Wed, 16 October 2013 22:13 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CEE11E82ED for <dnsext@ietfa.amsl.com>; Wed, 16 Oct 2013 15:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVf0RZLlkmuf for <dnsext@ietfa.amsl.com>; Wed, 16 Oct 2013 15:13:00 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8B31F11E82BE for <dnsext@ietf.org>; Wed, 16 Oct 2013 15:12:59 -0700 (PDT)
Received: from kopoli (e179165194.adsl.alicedsl.de [85.179.165.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M8eMt-1VjACz2TUh-00vQTq; Wed, 16 Oct 2013 18:12:57 -0400
From: Hosnieh Rafiee <ietf@rozanak.com>
To: Jay Daley <jay@nzrs.net.nz>
References: <B677F769-D8AF-4EC8-9C58-1116B840AA49@nzrs.net.nz> <001a01ceca53$c6fb3010$54f19030$@rozanak.com> <3DFAFF6B-E090-4276-8025-C5FF52C529D5@nzrs.net.nz> <000001cecab7$b7bf0c20$273d2460$@rozanak.com> <5F35EC3E-A4E9-43C0-B808-A66354D6FDC9@nzrs.net.nz>
In-Reply-To:
Date: Thu, 17 Oct 2013 00:12:48 +0200
Message-ID: <000201cecabc$dc64f7b0$952ee710$@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: AQNPbtY7r0spbIykxCLUUtreV80m/QK2S9e9Aa9gewUB6KXQyAJtDTORlrC7XWCAAAWNYA==
Content-Language: en-us
X-Provags-ID: V02:K0:3RV49TnckpopC6wrEDN5ojndAbjufRouacASYT2njBv bgjn+S4FGms1ccfRT/RkqlQXJ9QYH8Fm90KGy6z3f9yu/AmmT/ c8rbWGl2S7I+hYKRodIn6GlbNK5hanHUVTuS4VAx9fFvrw03GQ MM1KoAfBEbfKlPd6H/20hIb9Wi7zw3+h2a8Sy+D6bkYJiPmLvu ux/t5cw3fzb4SrOjsOnaCYsZC4T5d17rqQbelXJQoazaGlGxGj Oac/qGW2VOIWfR3TrthwhPneGai5s89UygMjR+P5QWZ2QKkwGN gWf1K8ZjSYQI8u2NSLUgR8+UaNtCgzPA6T6wauLYGSaaSb9JeR JV0NR635uqXtMvbenEec=
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Extending UPDATE to add/remove zones
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2013 22:13:06 -0000

Sorry I forgot to submit it to the list ...

>No Hosnieh I'm not falling for that.  If you think there is any
overlap/conflict/interaction between my proposed work and the cga-tsig draft
then please >identify it and I will address it.  

>To be clear, since it appears to me that you might not have understood, the
only idea I am floating around TSIG is that a DNSKEY record is given to a
>nameserver with the intention that is should use to authenticate (via TSIG)
a zone transfer request for a new zone that it is asked to serve as a slave.

I am attempting to rephrase my question. Correct me if I am wrong... I think
DNSKEY is for DNSSEC and not for TSIG. TSIG uses shared secret and it is
added to DNS configuration file (isn't stored in any record in database) .
dissimilar to a part of DNSSEC it is not public key cryptography. This means
that you cannot add the shared secret in DNSKEY for authentication. Security
problem... TSIG might use TKEY which is different than DNSKEY. 
Secondly, I guess addressing TSIG here does not really make sense as you are
not fully addressing security but you're planning to make the DNS update
more efficient. So, I suggest that you only think about  making the Update
more efficient and let other approaches like other RRs TSIG, cga-tsig secure
your approach. 

Thanks,
Best, 
Hosnieh