Re: [eppext] Stephen Farrell's Discuss on draft-ietf-eppext-keyrelay-11: (with DISCUSS and COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 17 December 2015 16:03 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 23CA51B2F0B; Thu, 17 Dec 2015 08:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 yZ2cL7hhdQzU; Thu, 17 Dec 2015 08:03:43 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166001B2EFB; Thu, 17 Dec 2015 08:03:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E83C1BEAF; Thu, 17 Dec 2015 16:03:40 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbmYn98s4zJx; Thu, 17 Dec 2015 16:03:39 +0000 (GMT)
Received: from [10.87.48.95] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 11B02BEA1; Thu, 17 Dec 2015 16:03:39 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450368219; bh=D72dGcX6TSfVkYI43h2qe5X8DhfEGu6oEBmJI1h/LZo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=iBgqdqktRtY4F+DVez8mi0QogvtwmynKzIL2mI5+vwyFV4aOVyBrEsTVx2x5y+IjI JM2aBcqlRiWuZ8pNfB/vrvdrq2Epuz+bF5jRQRZBNfS6yK+cpYBC8B0Z0Ud2Wf8g8A q4d755xPbNMeGPLwCTVBKImVNNNPngO0fGvi4nDs=
To: Rik Ribbers <rik.ribbers@sidn.nl>
References: <20151215114126.29062.93034.idtracker@ietfa.amsl.com> <94ACD476-6EF9-4531-8F98-00409A6C26E6@sidn.nl> <5672C7C0.70104@cs.tcd.ie> <0E771564-6F7F-4D52-9382-E3D4EA363043@sidn.nl>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5672DCDA.90105@cs.tcd.ie>
Date: Thu, 17 Dec 2015 16:03:38 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <0E771564-6F7F-4D52-9382-E3D4EA363043@sidn.nl>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/vGOmcZUnUrHCS0xxDDiX89oOqMI>
Cc: "draft-ietf-eppext-keyrelay@ietf.org" <draft-ietf-eppext-keyrelay@ietf.org>, "eppext-chairs@ietf.org" <eppext-chairs@ietf.org>, Ulrich Wisser <ulrich@wisser.se>, The IESG <iesg@ietf.org>, Marc Groeneweg <Marc.Groeneweg@sidn.nl>, eppext <eppext@ietf.org>
Subject: Re: [eppext] Stephen Farrell's Discuss on draft-ietf-eppext-keyrelay-11: (with DISCUSS and COMMENT)
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: <https://mailarchive.ietf.org/arch/browse/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, 17 Dec 2015 16:03:45 -0000


On 17/12/15 15:59, Rik Ribbers wrote:
> Hello Stephen,
> 
> counter proposal:
> 
> 
> In this document we define an EPP extension to sent DNSSEC key material 
> between EPP clients. This allows DNS operators to bootstrap automatically, reliable and 
> securely the transfer of a domain name while keeping the DNSSEC chain of trust intact. 

So that doesn't address the exact point that confused me
which was that you're only defining how to do things in
one way where new public keys go from gaining -> losing.
That is the crucial point you need to make.

Secondly, acking that there are other ways in which it
can be done would be good too.

S.

> 
> Gr,
> Rik
> 
>> Ok, so it's option (a) which is fine. But don't you need to
>> say that in the document? I initially assumed you were doing
>> (b) which lead to a confusing read. I'd suggest adding a bit
>> of text like this near the start:
>>
>> "This specification describes a way to use EPP to allow a
>> gaining DNS operator to send new public keys to a losing
>> DNS operator. Having those new keys signed in the DNS before
>> transitioning to the gaining DNS operator means there need
>> not be any gap in service when new private keys (at the gaining
>> DNS operator) are used to sign DNS records. While there are
>> other ways of managing keys during transitions, only this
>> method is described in this specification."
>>
>> Cheers,
>> S.
>>
> 
>