Subject: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt

From: Antoin Verschuren <[email-masked]>
Date: Thu, 24 Jan 2013 09:21:40 +0100

Hi all,

This draft may be of interest to this list.
At SIDN, we have documented how we intend to implement secure
transfers of DNSSEC domains and this draft is to describe the EPP
command we're going to use for that so it may be standardized.
Comments are welcome to the authors or on this list.

A new version of I-D, draft-gieben-epp-keyrelay-00.txt
has been successfully submitted by R. (Miek) Gieben and posted to the
IETF repository.

Filename:	 draft-gieben-epp-keyrelay
Revision:	 00
Title:		 Key Relay Mapping for the Extensible Provisioning Protocol
Creation date:	 2013-01-20
WG ID:		 Individual Submission
Number of pages: 11
URL:
http://www.ietf.org/internet-drafts/draft-gieben-epp-keyrelay-00.txt
Status:          http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay
Htmlized:        http://tools.ietf.org/html/draft-gieben-epp-keyrelay-00

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for the purpose of relaying DNSSEC key material
   from a one registrar to another.  The mapping introduces <keyrelay>
   as a new command in EPP.

   This command will help facilitating a transfer of a domain while
   keeping DNSSEC's chain of trust intact.

The IETF Secretariat

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 24 Jan 2013 11:27:28 +0100

> Comments are welcome to the authors or on this list.

Hi,

interesting draft. On the first glance, I'd like to note the following:

1. why is the use of the authinfo only optional? Isn't it better
    to make it mandatory and reject the submission if the authinfo
    is incorrect? In this case, the poll message does not need to
    contain the authinfo.

2. The current registrar does not know from which registrar the
    key data is coming. In case of problems, he is unable to contact
    the respective registrar. Also, he is unable to determine whether
    the keys come from different sources and need either to be
    combined or replaced.

3. How long shall the current registrar/name server operator add the
    DNSKEYs to the respective zone? If, for example, the registrant
    changes his mind and does no longer want the new registrar to
    transfer the domain to him, or wants to choose a different
    registrar, there is no way to indicate this. Alternatively,
    this could be solved by some kind of automatic timeout, i.e.
    if the the <keyrelay> operation is not repeated periodically,
    the current registrar shall remove the keys from the zone.
    If this period is not part of the registry policy, maybe
    the <keyrelay> command should contain a point in time until
    which the keys shall be added. If the (potentially) gaining
    registrar determines to need more time for whatever reason,
    he can submit another <keyrelay> command with the same keys,
    but a later date. Of course, the current registrar (or registry?)
    should check the time for reasonable limits.

Regards,

Klaus

---

From: James Mitchell <[email-masked]>
Date: Thu, 24 Jan 2013 22:08:14 +1100

Interesting draft. I hope that registrars warm to the idea and implement
it. A few high level questions/comments:

Implementing this is of arguable benefit to a registrar on the losing end.
Do you have a plan to encourage registrars to use it such that it will see
success? Do you have the buy in from existing registrars?

Keyrelay messages provide the losing registrar with early notification of
an imminent transfer. Do you foresee any potential issues with this, for
example the losing registrar attempting to (intentionally or accidentally)
block or delay the transfer. I'm thinking that a registrar could be
justified in updating the domain authinfo a few days after giving it out
for security reasons, thus forcing the registrant to obtain a new authinfo
code for the transfer itself. This delay could cause the domain to pass a
critical date (for example an expiration date or other relevant date
depending on registry lifecycle and policy).

I would suggest that an error should be returned for uploading a key for a
domain name sponsored by a registrar who has not implemented this
extension. This may be considered an "optimisation" at the registry level,
however I question if early failure would better inform the gaining
registrar? If so a specific code/message may be described to promote
interoperability.

Would you consider including reasons under which a registry should or
should not reject the command? For example I would assume there is no
reason for this to succeed should no key material be associated with the
domain on receipt of the <keyrelay> command. Or would you suggest that the
registry not attempt to otherwise interfere with the processing of this
command?

I notice there is no feedback loop from the losing registrar to the
gaining registrar. I assume that the gaining registrar would have to poll
the child zone (with its own timeout) to begin relevant cache-busting
timers? Note that the losing registrar may not provide DNS services for
the given domain name. Or do you consider the transfer pending period of
ample time for caches to expire.

I would assume that a registry may delete an unread keyrelay message from
the queue should a transfer be completed successfully?

Some registrars may prefer to process the message queue in batch,
potentially increasing the time between submission to the server and
retrieval by the losing registrar. Do you foresee any need or reason for a
priority-based, or named message queue to better facilitate keyrelay?

Regards,

James

On 24/01/13 7:21 PM, "Antoin Verschuren" <[email-masked]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi all,
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.11 (GNU/Linux)
>
>iQEcBAEBAgAGBQJRAO8OAAoJEDqHrM883AgnGn8IAI2qQdBdXSYZULn3QlmwUSDS
>nL7QAyaDwTdd6hoc9nU8mMdBYQ7nGFewrhKrrrs5HNY/zxVPjsDgzyJ9duJ5Y9lL
>6TBdPU6zL+1d6gYqyxXWWzo8YnbsBSW3Vf0Nq1YCtdhPkbPOVQwHQKnHdkRr6cjh
>cMCPXTMfXGjLJ08fa6uKSX39S+s7H9iMHO9YwIk4MbNCeyWkwgMvSkSfqQdyQcrt
>Jx0zczOD/RAo55G8nQgSVMHh31h5e71t/qR4QKSsG5EOyDs4dQM3kOmqjBVX90wu
>WyRLtcxr0CYwyFSgltWYx7TEam/1vFLnoLSavUUT9SsbK/3IS+xb7WOaBs66m04=
>=XH3D
>-----END PGP SIGNATURE-----
>_______________________________________________
>provreg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/provreg

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 24 Jan 2013 13:22:27 +0100

> interesting draft. On the first glance, I'd like to note the

Hi Klaus, thank you for your feedback. Comments below.

> 1. why is the use of the authinfo only optional?

Because it is also optional in the EPP transfer command.
A registry may declare a transfer token mandatory in local policy, but
a registry may also determine that transfers that are not
authenticated by a token will proceed if the losing registrar does not
object within a certain time frame. A registrar may object if the
transfer is not authenticated by a token, but he may also choose not
to object, again by his local policy.

> 2. The current registrar does not know from which registrar the key
> data is coming. In case of problems, he is unable to contact the
> respective registrar. Also, he is unable to determine whether the
> keys come from different sources and need either to be combined or
> replaced.

This is a very good suggestion. We will update the message queue
format to include the keyrelaying registrar in the next version of the
draft.

> 3. How long shall the current registrar/name server operator add
> the DNSKEYs to the respective zone?

This question is process, not syntax.
If it needs to be explained, it should be described in
koch-dnsop-dnssec-operator-change.
I understand your concern. If I were the DNS operator, I would delete
the key from my zone if I did not receive a transfer request within a
week after the keyrelay request, but again, that is process or local
policy and not syntax, and we don't think we need a trigger from the
registry for that. We want to keep the keyrelay command as simple as
possible for the registry, and leave the logic to the registrars and
DNS operators who are in control of the process anyway.

- -- 
Antoin Verschuren

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 24 Jan 2013 14:13:32 +0100

> Hi Klaus, thank you for your feedback. Comments below.

Hi Antoin,

> to object, again by his local policy.

Ok, although I consider the support for transfers without authinfo as a backward 
compatible feature no longer required and desired today.

> This question is process, not syntax.

I cannot agree. There are certain expectations with the protocol, namely that 
the current registrar performs the necessary steps to have the DNSKEYs published 
on the domain's name servers, and this is already "process". But defining only 
the addition and not the removal is only a half thing. Without clear semantics, 
i.e. with uncertainties about the consequences of its use, the value of a 
protocol decreases a lot. Of course, the semantics need not to fully cover 
Peter's/Marcos' paper.

Regards,

Klaus

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 24 Jan 2013 16:43:57 +0100

Op 24-01-13 12:08, James Mitchell schreef:
> Interesting draft. I hope that registrars warm to the idea and
> implement it. A few high level questions/comments:

Hi James, thank you for your comments.

> Do you have a plan to encourage registrars to use it such that it
> will see success? Do you have the buy in from existing registrars?

We have discussed 3 possible options for DNSSEC transfers with our
registrars. The most important outcome is that the registrars want to
stay in control of the process, and choosing this method over for
example going insecure during a transfer should be at the sole
discretion of the gaining registrar even during the process. It is an
optional process, not mandatory. (At least not by us, but a registrant
may demand it)
They all agreed though, that at least one secure transfer method
should be implemented by the registry and be available, and the method
described in koch-dnsop-dnssec-operator-change was supported with the
consensus of our registrars. As for buy in, I cannot say what the
promises of our registrars are worth, but most of them told us that
they realize that if they don't implement this on their end for
customers leaving, then they won't have any new satisfying customers
that would come to them.
One proof of buy in that I do have is that Bert Hubert's PowerDNS
(Which has a >50% marketshare in .nl) has recently built a feature in
their DNS software specifically to support this transfer method.

> Keyrelay messages provide the losing registrar with early
> notification of an imminent transfer. Do you foresee any potential
> issues with this, for example the losing registrar attempting to
> (intentionally or accidentally) block or delay the transfer.

Let the market know who that registrar is, and he will certainly loose
customers. Those sort of games don't work out well in the long run I
would say. It happens today, and it will happen in the future. I
aggree keyrelay does give advance notice that a customer may be
leaving, but if you are a good customer, you would have informed your
supplier within the notice period to end your contract anyway wouldn't
you ?

> I would suggest that an error should be returned for uploading a
> key for a domain name sponsored by a registrar who has not
> implemented this extension. Would you consider including reasons
> under which a registry should or should not reject the command?

We do not reject anything, we just relay. In a fixed syntax.

The question you could ask is what harm does it do if a registrar gets
a keyrelay message in it's message queue and does not know how to
handle it, or chooses not to handle it. Should the registry mandate
that he handles it? We don't mandate anything, we just facilitate
registrars that want to do secure transfers. We are no dictator nor god.

As a registry, you could choose not to relay for domains that
currently don't do DNSSEC, but there may be use cases where even a
domain without DNSSEC can benefit from a keyrelay command. For example
if the loosing dns-operator can't sign, but has agreed to pre-publish
his customers future ZSK.

For registries that do want to control their registrar's business
processes, I'm open for suggestions of such error messages, but we
won't ever use them as we just simply do what our customers want us to
do and relay the key. It does nothing to the registration data or status.

> I notice there is no feedback loop from the losing registrar to
> the gaining registrar. I assume that the gaining registrar would
> have to poll the child zone (with its own timeout) to begin
> relevant cache-busting timers?

The feedback loop is over DNS indeed.
The only reason we need this keyrelay command is because we cannot
relay the new key over DNS or any other secure channel. It's
documented in koch-dnsop-dnssec-operator-change

> Note that the losing registrar may not provide DNS services for the
> given domain name. Or do you consider the transfer pending period
> of ample time for caches to expire.

It's the dns-operators and registrars that control that process and
it's timing.
We only describe the EPP syntax because the registry is the middle
man, and communication with the registry is over EPP. Communication
between registrars, registrants and their DNS operators can be over
EPP, but it usually isn't. It's out of scope for this document,
thought we do mention in the security section that that communication
channel should also be authenticated, but it's not to us to mandate how.

> I would assume that a registry may delete an unread keyrelay
> message from the queue should a transfer be completed
> successfully?

That's local policy.
It's not defined in the current EPP RFC's that messages should be
deleted from the message queue by the registry. It's only defined how
a registrar can delete messages from it's queue after he has read them.
As for us, we just leave them there as long as the registrar does not
delete them. They do no harm.

> potentially increasing the time between submission to the server
> and retrieval by the losing registrar. Do you foresee any need or
> reason for a priority-based, or named message queue to better
> facilitate keyrelay?

If they read their message queue in batch, it's their thing.
How fast registrars or DNS operators should work is not our call.
I think it's their customers that decide if it's a good thing.
A DNSSEC transfer process takes time anyway. And it's not only reading
the queue, it's also what you do with the output and how fast you
provision the relayed key. We have nothing to say about how fast some
DNS operator handles it's customers requests.

- -- 
Antoin Verschuren

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 24 Jan 2013 17:44:22 +0100

Op 24-01-13 14:13, Klaus Malorny schreef:
>> 
>>> 3. How long shall the current registrar/name server operator
>>> add the DNSKEYs to the respective zone?
>> 
> I cannot agree. There are certain expectations with the protocol,
> namely that the current registrar performs the necessary steps to
> have the DNSKEYs published on the domain's name servers, and this
> is already "process".

Ah, I see how you look at it.
If that's the case, then we should make DNSSEC mandatory, which it
isn't. (though I would like it :-))

Secure transfers are not mandatory as well.
The only thing koch-dnsop-dnssec-operator-change describes is "if you
want to do a secure transfer, this is how you can do it".
We don't say you MUST do secure transfers because there is allways an
alternative to go insecure and we cannot mandate DNSSEC.

So if a key is relayed to a registrar, it is expected that he relays
the key to the DNS operator that is appointed by the registant. The
DNS operator can then publish the key to satisfy his customer, but we
have no contractual control over the DNS operator nor any RFC to make
that compulsory.

I guess we could have an expiration timer on the key, but who should
set that timer then ? Let's say a regular secure transfer can be done
in 3 days, what is a reasonable timer? 1 week ? And should the gaining
registrar set that timer ? And what if a gaining registrar sets the
timer to 1 year? Should the registry prohibit that by local policy ?
So suppose a registry does set a local policy of max 2 weeks for the
timer.
Then the timer can also be set by the losing registrar based on the
local policy of the registry, and we don't have to communicate that
timer over the protocol. It can be set in the cooperating DNS
operator's provisioning system, or even be deleted by hand at will.

The only thing a keyrelay command does is relay a key to facilitate a
secure transfer process for those that want on both sides, but that is
not mandatory to implement for every registrar or DNS operator.

- -- 
Antoin Verschuren

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 24 Jan 2013 18:09:14 +0100

Hi Antoin,

while it would be a bit too lax for me, if it is the desired design principle to 
give no assurances about what the registrar does with the DNSKEY data in the 
message, you also need not to give any assurances on the expiration timestamp I 
suggested to be relayed along with the DNSKEYs. Let it simply be a hint to the 
(potentially) losing registrar.

Regards,

Klaus

---

From: "Gould, James" <[email-masked]>
Date: Thu, 24 Jan 2013 20:51:07 +0000

Antoin,

The draft looks to be a good starting point.  Below is some feedback which overlaps a little with Klaus's feedback:

1. I too believe that the authinfo should be a required element.  This is useful for the losing registrar to verify prior to taking action.  
2. I find it interesting that this is the first example of an EPP protocol extension.  You might want to consider making this into a mapping where the object is keyrelay.  The create would create the keyrelay and the info response would be used in the poll message.  You can even generate a server unique identifier for the tracking of the keyrelay (was is dequeued and potentially to enable the losing registrar to mark it as accepted or rejected).  This might be over-engineering, but making it into an object with various commands (create, update, info, delete) to have the registry tracking the flow might be of use.
3. You might want to allow the gaining registrar to pass the key along with the associated set of DS records if the registry supports the DS Data Interface of RFC 5910.  In this case the losing registrar doesn't need to generate the DS and update the domain in the registry.  I wouldn't not recommend having the registry do any automatic DS updates, so the losing registrar would need to support setting the appropriate DS.  

JG

James F. Gould
Verisign

________________________________________
From: [email-masked] [[email-masked]] on behalf of Klaus Malorny [[email-masked]]
Sent: Thursday, January 24, 2013 12:09 PM
To: [email-masked]
Subject: Re: [provreg] Fwd: New Version Notification for        draft-gieben-epp-keyrelay-00.txt

Hi Antoin,

Regards,

Klaus

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 25 Jan 2013 10:26:52 +0100

Op 24-01-13 18:09, Klaus Malorny schreef:

> while it would be a bit too lax for me, if it is the desired
> design principle to give no assurances about what the registrar
> does with the DNSKEY data in the message, you also need not to give
> any assurances on the expiration timestamp I suggested to be
> relayed along with the DNSKEYs. Let it simply be a hint to the

Hi Klaus,

We have no principal objection to an optional expire field in the
keyrelay command just because we do not see any use for it in the
experiences with our registrars, but if other registries might want to
force their registrars by policy to have their 3th party DNS operators
to enter resource records in DNS for a specific time, we wish them luck.

So how would such an expire field look like?
Would it be an expire timer, like a TTL, or an expire date (not valid
after yyyymmdd, unixtime, someting else?)
Do you have any sugestion for a field definition?

- -- 
Antoin Verschuren

---

From: Miek Gieben <[email-masked]>
Date: Fri, 25 Jan 2013 11:18:16 +0100

[ Quoting <[email-masked]> in "Re: [provreg] Fwd: New Version Noti..." ]
> Do you have any sugestion for a field definition?

I think using the <expiry> element from 5730 is the right thing to do.

 Regards,

-- 
    Miek Gieben                                               http://miek.nl

---

From: David Peall <[email-masked]>
Date: Fri, 25 Jan 2013 12:20:54 +0200

This is a great concept.

It would be useful for the request for a keyrelay to create pending 
action. This allows the registry to optionally perform some validation 
steps; to deliver the poll message to the losing registrar; to get a 
response back from the registrar as to the success of the request; to 
perform a validation of the response.  Then return this pending result 
to the gaining registrar provide feedback and thus complete the transaction.

Possible issue could be the request for invalid DNSKEY data to be 
inserted that can crash bind?

Regards
--
David Peall
Domain Name Services

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 25 Jan 2013 11:40:31 +0100

On 25/01/13 10:26, Antoin Verschuren wrote:
>
> Hi Klaus,
>
> We have no principal objection to an optional expire field in the keyrelay
> command just because we do not see any use for it in the experiences with our
> registrars, but if other registries might want to force their registrars by
> policy to have their 3th party DNS operators to enter resource records in DNS
> for a specific time, we wish them luck.
>
> So how would such an expire field look like? Would it be an expire timer,
> like a TTL, or an expire date (not valid after yyyymmdd, unixtime, someting
> else?) Do you have any sugestion for a field definition?
>

Hi Antoin,

since the submission time may differ from the read time of the message (although
likely only minutes), I suggest not to use a relative time, but an absolute,
ideally the XML Schema data type "dateTime".

BTW, I am still a bit puzzled that you and/or registrars see no use for that. 
With a registrar hat on, I wouldn't want to accept arbitrary DNSKEY records from 
third parties and keep them for unlimited time in the zone. But maybe I am in a 
negligible minority ;-)

Regards,

Klaus

---

From: Miek Gieben <[email-masked]>
Date: Fri, 25 Jan 2013 12:35:37 +0100

[ Quoting <[email-masked]> in "Re: [provreg] Fwd: New Version Noti..." ]
> action. This allows the registry to optionally perform some
> validation steps; to deliver the poll message to the losing
> registrar; to get a response back from the registrar as to the
> success of the request; to perform a validation of the response.
> Then return this pending result to the gaining registrar provide
> feedback and thus complete the transaction.

No, want to keep this relaying step as simple as possible. Any transactions
which may or may not follow after this are up to the registrar(s).

> inserted that can crash bind?

Also up to the losing registrar.

 Regards,

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 25 Jan 2013 12:52:54 +0100

Op 24-01-13 21:51, Gould, James schreef:
>> 
> The draft looks to be a good starting point.  Below is some
> feedback which overlaps a little with Klaus's feedback:
> 

Hi James, thank you for your feedback.

> 1. I too believe that the authinfo should be a required element.
> This is useful for the losing registrar to verify prior to taking
> action.

Ok, that's 2 to 1 then. We can live with a required authinfo element,
we use transfer tokens as well.
I guess registries that don't use tokens can just fill in bogus tokens.

So can sombody explain why authinfo is not mandatory in the transfer
command and should be mandatory here ?
Or do you say it should be mandatory in the transfer command as well
but it's too much work to update the RFC ?

(In my belief, we just design the protocol, not the registry policy.
Registrars that require tokens can still refuse to follow up on a
keyrelay that is not authenticated.)

> 2. I find it interesting that this is the first example of an EPP
> protocol extension.  You might want to consider making this into a
> mapping where the object is keyrelay.

We were advised not to do so.
First of all, the registry does not need to do anything with the data
but relay to the current registrar of record.
It does not change any registry data. The EPP channel is only used to
facilitate DNS operators that have no other secure communication
channel, but those that do can happily use that other channel, so not
all keys that are transfered by DNS operators might pass the registry.
So the registry does not need to maintain state or track any of these
relay commands.
Though it would still be nice if we could track all the keys that were
relayed through the registry, it would make implementation more
complex, and we heard from some registries that they would only
implement the strictly necessary. A keyrelay without tracking would
not affect their current design, and could be built without touching
the database.
So the question we have is should we design with all the nice to have
features and no implementations, or have implementations first. We
chose the last, KISS, expand if necessary.

> 3. You might want to allow the gaining registrar to pass the key
> along with the associated set of DS records if the registry
> supports the DS Data Interface of RFC 5910.  In this case the
> losing registrar doesn't need to generate the DS and update the
> domain in the registry.  I wouldn't not recommend having the
> registry do any automatic DS updates, so the losing registrar would
> need to support setting the appropriate DS.

First, as the largest DNSSEC registry around, we don't use the DS data
interface at all, but use the Key data interface. The main reason is
that we already envisioned secure DNSSEC transfers where DNSKEY data
needed to be moved around, and we didn't want our registrars to use DS
data for some commands, and DNSKEY data for other commands. Just use
DNSKEY all the time, we will handle DS at the parrent.

But that aside, we did consider on big keyrelay/DS
rollover/transfer/NS change command but it had too many disadvantages.
There are many timers and states involved in DNSSEC, and especially in
DNS operator changes.
When all data comes in at once at the registry, it means the registry
must set and guard all the timers that are involved, and do all the
checks of steps that need to be performed in order. It mandates the
registrars and DNS operators to follow that complex schema, and things
really break if they don't.
By cutting things up in standard small steps, the registrar is in
control, and can initiate every step based on his own judgment and
standard timers he uses.
By breaking it up in steps, it also means commands can be reused. They
are standard steps. A transfer is for example only a change of
registrar of record, and that remains so. An NS change is also no
different with or without DNSSEC.
But the major drawback is determining the registrar of record, and
which registrar can request changes at the registry. By introducing
this keyrelay command that does not change any data at the registry,
the losing registrar stays in control of the domain at the registry
until a clean transfer command has been issued. Changes to the domain
before the transfer are done by the losing registrar, and changes
after the transfer are done by the gaining registrar.

- -- 
Antoin Verschuren

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 25 Jan 2013 13:23:49 +0100

Op 25-01-13 11:40, Klaus Malorny schreef:

> BTW, I am still a bit puzzled that you and/or registrars see no use
> for that. With a registrar hat on, I wouldn't want to accept
> arbitrary DNSKEY records from third parties and keep them for
> unlimited time in the zone. But maybe I am in a negligible minority
> ;-)

I couldn't agree with you more, you're not a minority :-)
But the question is "who sets the timer?"
Is it the gaining operator, the registry, or the losing operator that
sets the timer.
As losing operator entering the data in my DNS, I would always set the
timer myself, regardless of what the gaining operator or registry
"advises" me over the protocol. It's my DNS, so I decide if I put
anything in it, and for how long.
It's much harder for me to provision different timers depending on
registry or gaining operator's preferences, so I would just use one
default timer that I as operator find acceptable.
When the losing operator overrides the advised timers anyway, I just
don't see the need to relay an advised timer over the protocol when it
is consequently ignored.

- -- 
Antoin Verschuren

---

From: Miek Gieben <[email-masked]>
Date: Fri, 25 Jan 2013 13:34:09 +0100

> > unlimited time in the zone. But maybe I am in a negligible minority

<SNIP>

> don't see the need to relay an advised timer over the protocol when it

If everybody cooperates such a timer can be used for something good. I.e.
dropping the key when the timer expires. 

I think it is a small and worthwhile addition.

grtz Miek

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 25 Jan 2013 13:40:13 +0100

>   from a one registrar to another.  The mapping introduces <keyrelay>

I think the draft in a quite complicated way mixes up transfer of domains between registrars and change of DNS operator. Those are two very different operations, and they should not be mixed up.

Further, I do not understand the real need for a transfer of the key from the loosing to the gaining DNS operator, as I am a person that rather believe in an overlap in DS in the registry. I.e. DS created by the loosing DNS operator is published in parent zone until the zone is stable under DS from the gaining DNS operator.

   Patrik

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 25 Jan 2013 14:47:01 +0100

Op 25-01-13 13:40, Patrik F￤ltstr￶m schreef:
>> Abstract: This document describes an Extensible Provisioning
>> Protocol (EPP) extension mapping for the purpose of relaying
>> DNSSEC key material from a one registrar to another.  The mapping
>> introduces <keyrelay> as a new command in EPP.
> 
> I think the draft in a quite complicated way mixes up transfer of
> domains between registrars and change of DNS operator. Those are
> two very different operations, and they should not be mixed up.

You just stole my line Patrik :-).
As advocate of clearly separating registrar and DNS operator roles, I
can assure you that both the transfer and this EPP draft do so, and
I'm here to guard that separation.
But I can understand your worries.
perhaps we were not clear in explaining how a DNS operator change
would use this communication channel when no registrar change would
take place. I'm thinking of something along this line:
"A registrar may also use this keyrelay command to relay a key to his
own message queue. This is to accommodate a fully automated DNS
operator change when only 3th party DNS operators change, but the
registrar stays the same."
If you have better text, please let me know.

> Further, I do not understand the real need for a transfer of the
> key from the loosing to the gaining DNS operator, as I am a person
> that rather believe in an overlap in DS in the registry. I.e. DS
> created by the loosing DNS operator is published in parent zone
> until the zone is stable under DS from the gaining DNS operator.

Hmm, perhaps you should read
draft-koch-dnsop-dnssec-operator-change-04 first.

First of all, the issue we try to solve here is that a key needs to
travel from gaining to losing DNS operator over a secured channel. We
use the administrative channel for that as no other direct channel
exists:

[DNS operator]-[Registrant]-[Reseller]-[Registrar]-[Registry]-
[Registrar]-[Reseller]-[Registrant]-[DNS operator]

In this draft, we describe the EPP message that will only be used in
part of this channel: [Registrar]-[Registry]-[Registrar]

How secure communication takes place between the other players
involved is out of scope as they usually don't use EPP for that
communication. See also the security section of the draft.

A key also needs to travel from loosing (current) to gaining DNS
operator, but we can use DNS and validation for that when the current
zone is DNSSEC signed.

This step of relaying the keys between gaining and losing operator is
only the first step in a process where at the 3th step double DSes
exist at the parent. But in order for either one of those DSes to
validate child data during the NS change Both ZSK's need to be present
in both zones at both operators.

- -- 
Antoin Verschuren

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 25 Jan 2013 15:22:13 +0100

> You just stole my line Patrik :-).

:-)

> take place.

Obviously not! Ha ha ha!

If you look at the epp commands, in reality the change of NS (and dnssec data, i.e. DS) in parent zone is made by one and only one registrar. Either it is made by the gaining or donating registrar.

> I'm thinking of something along this line:

I think you should explain in what order various things happens. Think about it as a series of epp commands that both the gaining and donating registrars have to make, and a 2nd case where the registrar is not changing.

> draft-koch-dnsop-dnssec-operator-change-04 first.

I have read it some time ago, and now read it again.

I do not agree with some of the requirements in there, and I think that design is far to complicated because of those requirements.

For example I think we in the DNSSEC world do not agree on what "validation failure" means. That is a term that is essential to agree on when reading the koch draft.

If you have two DS in the parent zone, and only one of them can validate the KSK, ZSK and signature, is that a failure?

> travel from gaining to losing DNS operator over a secured channel.

Ok, I now understand where the disagreement is. I do not think it has to move. And if something have to move (up to the gaining dns operator) it can get the data via normal DNS queries. I.e. the KSK that is used in the old zone.

But also, we already know the tricky part is for the gaining DNS operator to get the zone content in the first place from the donating DNS operator....and if we solved the general case, it would solve many cases.

> We

The way I have moved things in .SE is by having double DS in parent zone. One for the old zone and one for the new. Each one of the old and new zones only have its content (KSK, ZSK, and other RRSets) signed with the ZSK of that version of the zone.

I still claim that works. In practice.

The trouble is to have a gaining registrar add a DS while keeping the old DS, and then only removing the old DS when one is pretty darn sure the zone data for the old zone has expired in all caches.

But I promise to talk with Peter Koch next time I meet him so that I get told that I am wrong :-)

   Patrik

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 25 Jan 2013 16:30:00 +0100

Op 25-01-13 15:22, Patrik Fältström schreef:
> 
> If you look at the epp commands, in reality the change of NS (and
> dnssec data, i.e. DS) in parent zone is made by one and only one
> registrar. Either it is made by the gaining or donating registrar.

Agreed

> I think you should explain in what order various things happens.

This is described in draft-koch-dnsop-dnssec-operator-change-04.
This EPP draft only describes the missing EPP command that does not
exist today and is needed as one of the steps in
draft-koch-dnsop-dnssec-operator-change-04. We need to get a key from
the gaining to the losing DNS operator.

> If you have two DS in the parent zone, and only one of them can
> validate the KSK, ZSK and signature, is that a failure?

Not to me.

> Ok, I now understand where the disagreement is. I do not think it
> has to move.

You are wrong.

> The trouble is to have a gaining registrar add a DS while keeping
> the old DS, and then only removing the old DS when one is pretty
> darn sure the zone data for the old zone has expired in all
> caches.

We should discuss this on the dnsops mailinglist.

> I get told that I am wrong :-)

Peter has writen down the text for the draft, but the issue originates
with me, so I can answer as well.

The problem is that a cache may have cached the DNSKEY RRset from the
old zone, and while that is still valid the NS RRset changes at the
parent and the resolver recieves a new NS (or other) RRset from the
new child zone with a new signature from the new ZSK that is not
present in the cached DNSKEY RRset thus failing validation. This can
only be solved if both DNSKEY RRsets contain both ZSK's from the new
and old child zone. Same as you would do with a pre-publish ZSK rollover.

Transferring and keeping the old zone data on the new nameserver does
not help, because at some point in time, at least the NS RRset needs
to change and a new signature needs to be generated over it by a new
ZSK that is not present in the DNSKEY RRset. A signature with the old
ZSK over this new NS RRset cannot be generated because the old private
ZSK is not available for signing by the new operator.

Further discussion on this please on the dnsops mailinglist.

- -- 
Antoin Verschuren

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 25 Jan 2013 16:34:15 +0100

> Further discussion on this please on the dnsops mailinglist.

Of course.

   Patrik

---

From: Miek Gieben <[email-masked]>
Date: Fri, 25 Jan 2013 19:43:19 +0100

[ Quoting <[email-masked]> in "Re: [provreg] New Version Notificat..." ]
> > draft-koch-dnsop-dnssec-operator-change-04 first.

Patrick, now that the discussion moved to dnsop about this draft, do still feel
you have issues (with the text) about the keyrelay draft?
(And if so, do you have any proposed text :-) )

grtz Miek