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

Antoin Verschuren <ietf@antoin.nl> Wed, 16 December 2015 12:48 UTC

Return-Path: <ietf@antoin.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 404891B2D45 for <eppext@ietfa.amsl.com>; Wed, 16 Dec 2015 04:48:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.483
X-Spam-Level: *
X-Spam-Status: No, score=1.483 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 CGIYvekAwo2A for <eppext@ietfa.amsl.com>; Wed, 16 Dec 2015 04:48:06 -0800 (PST)
Received: from walhalla.antoin.nl (walhalla.antoin.nl [88.159.164.218]) by ietfa.amsl.com (Postfix) with ESMTP id CC77C1B2D40 for <eppext@ietf.org>; Wed, 16 Dec 2015 04:48:05 -0800 (PST)
Received: from [192.168.0.114] (unknown [192.168.0.1]) by walhalla.antoin.nl (Postfix) with ESMTPSA id E71F12803A3 for <eppext@ietf.org>; Wed, 16 Dec 2015 13:48:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antoin.nl; s=walhalla; t=1450270084; bh=9Hncsl4/Jx1Do17UQtFnI996t9eWR0mD1arr4SZ+leI=; h=From:Subject:Date:References:To:From; b=oy9GFmCx3cnku2R+4bSNnPrLDZMws1uUlD0EN7++uOeUcWPPUruCBvYX3djxnlZdk Xdt3Pbu4M0Qu2iQwe0VM8+gkKTreOAyQ5xhkMgcp9NQwgglFEpFWlcNTXeIcI7x+nq 5P/CCFOs5LbhCLA0VP7We69g/C9nL3+zVyA7Zrv4=
From: Antoin Verschuren <ietf@antoin.nl>
X-Pgp-Agent: GPGMail 2.5.2
Content-Type: multipart/signed; boundary="Apple-Mail=_CE04C76C-63CD-466B-A7D9-BEBC98262225"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Date: Wed, 16 Dec 2015 13:47:58 +0100
References: <C79DC7B0-5688-4F35-827E-AC0A34944108@antoin.nl>
To: eppext <eppext@ietf.org>
Message-Id: <BA476B21-584E-41E5-A2C6-C8DBDDD9C0A1@antoin.nl>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/nsFIJ1t930M9lbyjWQNh50tnTc0>
Subject: [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: Wed, 16 Dec 2015 12:48:07 -0000

Op 15 dec. 2015, om 21:10 heeft Rik Ribbers <rik.ribbers@sidn.nl> het volgende geschreven:

>> On 15 Dec 2015, at 12:41, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>> 
>> - Section 6: I'm surprised that you don't recommend or even note
>> that the gaining registrar/dns operator should be able to check
>> that the DNSKEY value it sees in XML is or is not the same as one
>> that is published in the DNS and verifiable there. Wouldn't that
>> kind of cross check be useful?
>> 
> 
> I agree that this is useful; proposed wording:
> 
> A client that uses this mechanism to send DNSSEC key material to another client COULD verify through DNS that the DNSSEC key material is added to the authoritative zone of the domain.
> 
> Please let me know what you think of this proposed wording.

I disagree with this wording, and with the problem statement.
A gaining DNS-operator is able to validate a key from the losing DNS-operator through the DNS as there is a chain of trust. That key from the losing DNS-operator therefor never needs to go over the EPP XML channel. People can trust it through DNS.

The use case for keyrelay is the other way round. The gaining operator initiates the transfer, The losing operator needs a secure channel to trust the key that is sent by the gaining operator as the losing operator cannot validate that key though DNSSEC since the delegation is still to the losing operator. Keyrelay is a solution to that bootstrap issue.
If at all, I would recommend NOT to trust the key from the gaining DNS-operator over DNS as it cannot be validated through DNSSEC.
The losing operator COULD check if the gaining operator has set up his DNS properly as a sort of pre-delegation check, but frankly I don’t believe that is his responsibility, and certainly in most registry policies not a reason to disapprove a transfer. On top of that, since there is no delegation, and thus no chain of trust, the responses can be spoofed so it would be an extra security risk if the gaining operator would rely on performing a pre-delegation check. A third party could block the transfer by spoofing the responses.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392