Re: [eppext] New draft for keyrelay available

Rik Ribbers <rik.ribbers@sidn.nl> Tue, 20 January 2015 08:02 UTC

Return-Path: <rik.ribbers@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 80AA81B2D92 for <eppext@ietfa.amsl.com>; Tue, 20 Jan 2015 00:02:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.294
X-Spam-Level:
X-Spam-Status: No, score=0.294 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 hyvGJauxAa-J for <eppext@ietfa.amsl.com>; Tue, 20 Jan 2015 00:01:57 -0800 (PST)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79251B2D82 for <eppext@ietf.org>; Tue, 20 Jan 2015 00:01:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding:mime-version; bh=HlE8BGSHQmXpcgXV1MHlOu6TuNVKG0kMVlHqCKKGoKw=; b=TDL6ouSp6sHI9JlWMYzsRsEnwGEkZ3/m3RkyjR8mGBA7DzUpf1C9GNXvQTv4jsNnH9WAhq1dyu1huC08jWLiSI2fBzCN+wiMo4LLW1aEQBByfKi7i2VF5tTOOwts8LUjW0v7Jm67J2xHBQdPMbiXyVccA8eLgCH5QREYjZ7hjMc=
Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id t0K81mtI026912-t0K81mtK026912 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Tue, 20 Jan 2015 09:01:48 +0100
Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0174.001; Tue, 20 Jan 2015 09:01:46 +0100
From: Rik Ribbers <rik.ribbers@sidn.nl>
To: "'Maarten Bosteels'" <maarten.bosteels@dnsbelgium.be>, Miek Gieben <miek@miek.nl>, "Gould, James" <JGould@verisign.com>, "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: [eppext] New draft for keyrelay available
Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEZqysAAANycgAALHHTMA==
Date: Tue, 20 Jan 2015 08:01:45 +0000
Message-ID: <C80127C588F8F2409E2B535AF968B768B9285C2F@kambx2.SIDN.local>
References: <C80127C588F8F2409E2B535AF968B768B927CDA8@kambx2.SIDN.local> <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <C80127C588F8F2409E2B535AF968B768B9280B52@kambx2.SIDN.local> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <AF040383-7DED-4DDA-A52A-F40978697DF9@dnsbelgium.be>
In-Reply-To: <AF040383-7DED-4DDA-A52A-F40978697DF9@dnsbelgium.be>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.2.152]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/wy7iyK5RTWtqxa4ICfRcQARHdAo>
Subject: Re: [eppext] New draft for keyrelay available
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: Tue, 20 Jan 2015 08:02:00 -0000

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer.

Kind regards,
Rik Ribbers

-----Original Message-----
From: Maarten Bosteels [mailto:maarten.bosteels@dnsbelgium.be] 
Sent: maandag 19 januari 2015 12:26
To: Miek Gieben; Gould, James; eppext@ietf.org
Cc: Rik Ribbers
Subject: Re: [eppext] New draft for keyrelay available

Hi all,

I agree with James that creating a Key Relay Object Mapping instead of mixing of a protocol extension for the command and an object mapping for the poll response seems simpler.
And I am all for simpler ;-)
At DNS Belgium we have in the past created extra verbs using a protocol extension, but in most cases it proved afterwards to be more appropriate to use an plain command/response extension or a new Object Mapping.
 

Like Miek, I also assume not many people care about this issue. I think for the following reasons:
A) Both options will work: it's a very technical choice with little impact on the actual users
B) I assume not many registries (and RAR's) are considering implementing key relay in the near future. But I'd love to be proved wrong here !


Miek or Rik, is the key-relay functionality implemented by SIDN actively used by many registrars ?  On both sides of the transfer/relay ?

Regards
Maarten




On 19/01/15 09:47, "Miek Gieben" <miek@miek.nl> wrote:

>[ Quoting <JGould@verisign.com> in "Re: [eppext] New draft for 
>keyrelay..." ]
>>All,
>>
>>I agree with Rik that more from the WG must weigh in on this.  I 
>>believe Rik and I understood fully each others perspective, but we 
>>simply don’t agree.
>>Please take some time to review the two different approaches and reply 
>>to the list with your opinion.
>
>I didn't see any replies, so I'm assuming not that many people care 
>about this issue.
>
>As one of the draft authors I think we should leave the draft in its 
>current state.
>
>/Miek
>
>--
>Miek Gieben
>
>_______________________________________________
>EppExt mailing list
>EppExt@ietf.org
>https://www.ietf.org/mailman/listinfo/eppext