Re: New Version Notification for draft-gieben-epp-keyrelay-00.txt

On 25 jan 2013, at 14:47, Antoin Verschuren <[email protected]> wrote:

> Op 25-01-13 13:40, Patrik F￤ltstr￶m schreef:
>> On 24 jan 2013, at 09:21, Antoin Verschuren
>> <[email protected]> wrote:
>> 
>>> 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.

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:
> "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.

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.

>> 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.

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?

> 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.

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
> 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.

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

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg