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

From: Antoin Verschuren <[email-masked]>
Date: Wed, 16 Dec 2015 13:47:58 +0100

Op 15 dec. 2015, om 21:10 heeft Rik Ribbers <[email-masked]> het volgende geschreven:

>> On 15 Dec 2015, at 12:41, Stephen Farrell <[email-masked]> 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