[eppext] FW: New draft for keyrelay available

[Rik Ribbers <[e-mail]>]

Forgot to include the list.... sorry

From: Rik Ribbers
Sent: vrijdag 30 januari 2015 22:30
To: 'Santosh Kalsangrah'
Subject: RE: New draft for keyrelay available

Hello Santosh,

Thx for the feedback. Here are my answers:


1)      This draft uses the validated trusted EPP channel. According to RFC5734, section 8 this must be a TCP/TLS connection. The idea is here that a registrar doesn't always know how or to whom the DNSSEC key material must be send. By using the registry EPP interface there is a secure and trusted path.

2)      In the draft we state that depending on the use case a server must determine what elements of the data must be used for 1) validating the request and 2) determining the registrar to relay the data to. For the keyrelay usecase this is  the authInfo element for 1) and for 2) the domainname is used.

3)      This is actually out-of scope for this specific draft. The mechanism is  to send the command and if the server approves (return EPP code 1000) the gaining registrar must assume the message is on the poll queue of the losing registrar. There is a different draft which describes the process of a secure domain transfer which describes the complete process (https://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-06 )

4)      This depends on the policy of the registry. For us a registrar must acknowledge the poll message what happens afterwards it out of our hands and depends on the registrars. There are several issues (e.g. the registrar is not always the DNS-operator) that are involved with the secure transfer of a domainname that are not covered here. This draft focusses on relaying  the keymaterial from registrar 1 and 2. Again see the draft https://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-06 for more information.

Kind regards,
Rik

From: Santosh Kalsangrah [mailto:[e-mail]]
Sent: vrijdag 30 januari 2015 21:36
To: Rik Ribbers; [e-mail]<mailto:[e-mail]>
Subject: RE: New draft for keyrelay available

Rik,

Here is my feedback, (actually questions:))


1.       It seems it's assumed that all EPP messaging between registrar 1<->registry<->registrar 2 proposed in this draft is over secure transport. Is that ok if either or both registrar(s) connects to registry over non-secure transport?

2.       How is key information validated by receiving registrar that it is what was sent by the  other registrar. Or how is sender assured that key information would be sent as is to other end? Or this is not important?

3.       How would gaining registrar be notified back that key info it has sent is acknowledged/read by losing registrar. Or is it that gaining registrar need not to know?

4.       In case if losing registrar does not support extension in this draft, what will happen to key info?

Thanks,
Santosh K

From: EppExt [mailto:[e-mail]] On Behalf Of Rik Ribbers
Sent: Thursday, January 08, 2015 7:12 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [eppext] New draft for keyrelay available

All,

As you (may) have noticed we submitted a new version of the keyrelay draft. In this draft we tried to solve all the open issues, remarks and feedback we received.

The major  changes are:

  1.  Introducing the <relay> command, and thus seperating the data and
       the command.

   2.  Updated the Introduction, describing the general use of relay vs
       the intended use-case of relaying DNSSEC key data.

   3.  Restructuring the document to make it more inline with existing
       EPP extensions.

In the end it has become a major rewrite and as always feedback is welcome.

Kind regards,
Rik Ribbers

________________________________






NOTE: This message may contain information that is confidential, proprietary, privileged or otherwise protected by law. The message is intended solely for the named addressee. If received in error, please destroy and notify the sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant and/or guarantee, that the integrity of this communication has been maintained nor that the communication is free of errors, virus, interception or interference.