Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback
Antoin Verschuren <antoin.verschuren@sidn.nl> Thu, 13 March 2014 09:39 UTC
Return-Path: <Antoin.Verschuren@sidn.nl>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1221A0928 for <eppext@ietfa.amsl.com>; Thu, 13 Mar 2014 02:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.453
X-Spam-Level:
X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 y5f5zE3EL4Zx for <eppext@ietfa.amsl.com>; Thu, 13 Mar 2014 02:39:35 -0700 (PDT)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6E71A090B for <eppext@ietf.org>; Thu, 13 Mar 2014 02:39:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=AmPovojEY51edRmFEItcZiwgTRpRqYPbt5X2xyvrOVw=; b=jtYOkzbYBw3o3zYCXKbsNmz0Y83TZxxQexvOQAXLGjILx6be38e4wpdXxhaU04hLjLK01/nR4K3AcAOtkVT95r6PGT7nisEaS4xcZB3XT8Vwm2z0Aa7/xx8AvBvwCa1DPFPf/yphQehTnbNLbFYwr5EbVX6IT2EHVQE+XoHdOjY=
Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by arn2-kamx.sidn.nl with ESMTP id s2D9dShS018749-s2D9dShU018749 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL); Thu, 13 Mar 2014 10:39:28 +0100
Received: from [94.198.152.214] (94.198.152.214) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 13 Mar 2014 10:39:23 +0100
Message-ID: <53217CCB.4060908@sidn.nl>
Date: Thu, 13 Mar 2014 10:39:23 +0100
From: Antoin Verschuren <antoin.verschuren@sidn.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Gould, James" <JGould@verisign.com>, "eppext@ietf.org" <eppext@ietf.org>
References: <CF44A31F.5969B%jgould@verisign.com>
In-Reply-To: <CF44A31F.5969B%jgould@verisign.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [94.198.152.214]
Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/i9MImdSnQlczhsGOfx_GWERGlJw
Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 09:39:38 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 op 11-03-14 17:36, Gould, James schreef: Hi James, Thanks for your suggestions. We have particularly looked at: > 2. Create a Command-Response Extension of the domain mapping that > creates a new keyrelay verb similar to the restore verb in RFC > 3915, which is an extension of an empty domain update. The server > can define who is authorized to invoke the new verb on the domain > name. > > By defining Key Relay as a new object or a new verb extension to > the domain object, you get all of the advantages of an object > mapping (extensions, client and server transaction identifier). > My recommendation is to go with option #2, since I view Key Relay > as a verb. In summary, I don’t believe there is the need to create > a protocol extension for this. One of the requirements from certain registries for keyrelay was that since keyrelay is only a "preparation communication step" for a DNS operator change that may or may not be followed by an NS change or combined transfer/NS change, they did not want any changes made to records owned by the registrar of record for a domain object. It's not compulsory to do this "communication" via the registry, it only facilitates registrars that have no other secure communication channel. Sometimes a keyrelay command is not followed by an NS change as the process is abandoned, and that should not lead to changes in the DB that need to be reverted. The process would then become more complex than necessary. Another requirement that we heard from especially gTLD registries is that a command for which it was necessary to change the database tables in a fundamental way would not be implemented by those registries. Since most EPP commands are processes that change an object in the registry DB and is only authorized by the current registrar of record, we looked at a way to do this communication step without even touching the DB. EPP keyrelay can be implemented without any changes to the registry DB, and only queries existing records. This is also how we implemented it. We only know of one other command that is NOT authorized by the current registrar of record for a domain object, and that is a transfer. But if authorized properly by an auth-info token, the goal of a transfer command is ultimately also to make changes to the domain object in the DB. Keyrelay does not intend to change anything to DB objects. That is ultimately done by an NS change that usually follows a keyrelay if the process is continued AND the loosing DNS operator cooperates. If the loosing DNS operator does not cooperate, a different change to the DB may follow, and it's complex to predict which action would follow. There is no default process flow, it's up to the gaining registrar which next step to take (Abandon, postpone, go insecure, transfer and leave delegation as is, ...), we want him to be in control. Could you elaberate on how a Command-Response Extension of the domain mapping would meet the requirement of not changing anything fundamental to the registry DB, nor creating a complex unpredictable state flow? How would the State Diagram similar to Figure 1 of RFC3915 look like for EPP keyrelay? Bear in mind, that a pending NS change state for a secure transfer cannot be held forever, nor can it be predicted what a reasonable period for that state is. It depends on DNS TTL values that are not prescribed nor verified in most registry policies. And since we want the registrant to be in control over his domain, it may well be that during a pending state, yet another registrar may invoke a keyrelay if the registrant chooses to change registrars because the process takes too long or there is another (technical) reason to change his delegation. So a state diagram is much more difficult to create than a state diagram for a grace period that is only dependent on 1 registrar and a state period defined by the registry's policy. By completely separating the "preparation communication" from the state of a domain object, we have avoided the need for a complex state diagram and fundamental changes to the registry DB. It also extends EPP with a new command type that may have other benefits in the future. For an (even more) elaborate explanation on how we came to this conclusion, we have written a white paper: https://www.sidnlabs.nl/uploads/tx_sidnpublications/wp_2013_EPP-keyrelay_v1.en.pdf > On 3/11/14, 9:23 AM, "Antoin Verschuren" > <antoin.verschuren@sidn.nl <mailto:antoin.verschuren@sidn.nl>> > wrote: > > Hi, > > I'd like to answer the question asked in London why EPP keyrelay > is not an object extension or domain update. > > Regular EPP commands are submitted to a registry by the current > registrar of record for that object in the database. Only the > registrar of record is allowed to change attributes to a domain > object. > > EPP keyrelay is a command that typically is sent to a registry by > a registrar NOT being the registrar of record for that domain > object. So the registrar sending the command is not permitted to > change anything in the database to that object. > > EPP keyrelay is therefor only a communication command, and the > domain object is only used to identify the registrar of record for > that domain object as a recipient. The domain object is only > queried to identify the registrar of record, but no attributes are > allowed to be changed. > > Hope that clarifies the questions raised in London. > > > _______________________________________________ EppExt mailing > list EppExt@ietf.org <mailto:EppExt@ietf.org> > https://www.ietf.org/mailman/listinfo/eppext > - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJTIXzKAAoJEDqHrM883AgnH/sIAKYi48zCXAmWXaNjBc+Jik22 /90SrAeV2E3nG9A3FvaM0+0F6lHH9oiKVNzveYD8E6+9pojOdw++scRENqAOuseh 0cE3XjvAZh6EQAt2HDKv4Be/LyX5ZnJR8iorecMSl8M0BGQhu7/EDZwD31gFe3kw ac5ePOijelbte4vIb1gN3WjqWbUjbavMJVxt7hQwL75km0uS3WUGdpo0YwKg3Xan zjSB/2G7tv0KDVoBIMsKnmTWoR38s4aEXTpdZqq1hJUDIwnwdvHwzbJjRq9a9yKV Hy3+KJfXZvGIPsiHQZBHLyY3vNJJnA3kKCRO7U7twOiBL5WLPyvaqEhscuJqbRs= =Xyh/ -----END PGP SIGNATURE-----
- [eppext] draft-ietf-eppext-keyrelay-00 Feedback Antoin Verschuren
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Antoin Verschuren
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Antoin Verschuren
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Christopher Browne
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Marc Groeneweg
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Hollenbeck, Scott
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Hollenbeck, Scott
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Antoin Verschuren
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Hollenbeck, Scott