From: Antoin Verschuren <ietf@antoin.nl>
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\))
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)
Precedence: list


--Apple-Mail=_CE04C76C-63CD-466B-A7D9-BEBC98262225
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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:
>>=20
>> - 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?
>>=20
>=20
> I agree that this is useful; proposed wording:
>=20
> 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.
>=20
> 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=92t =
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



--Apple-Mail=_CE04C76C-63CD-466B-A7D9-BEBC98262225
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCAAGBQJWcV2EAAoJEHda8rd0+iNRbywIAKbBWrlGw69xxzCp0yyyuewl
/CanW7HWK4dlEdbgeSNkcoHLsjvFF97uYuMtz3arzEgh0dPEKSEk1tJpjFVrVzvO
eDGO8Im+7YSzeHgQPZOHiLGy0FFsaz7Bhgeqqknje91BuqocmqVVLBqKqtFKGGyN
YuZz9GelFRfIekzJDuC7SNsj1/+K0lh3V64ICWF/5EBK7FeTyFAbKaxeVcXuwXxJ
ZUcM+StyJIqClE2stE4l1Wvms7j5mVxbwy4Biwoq0+tGwf6M9iVYJJ23Jx4XnV5+
+AjqFkWoFCMGxTSKTP6PhiwbSEcmMEbFasvFcy/4enRf9S6yEQNg73V/+NheCgE=
=+YzZ
-----END PGP SIGNATURE-----

--Apple-Mail=_CE04C76C-63CD-466B-A7D9-BEBC98262225--