Subject: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question

From: James Gould <[email-masked]>
Date: Tue, 09 Dec 2008 12:04:20 -0500

In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one usability
issue that I would like to get feedback from the existing implementations of
the extension.  

The specification allows adding (<secDNS:add>), removing (<secDNS:rem>), and
changing (<secDNS:chg>) DS data, but according to the XML schema they can¹t
be done at the same time.  Below is from the RFC 4210 XML schema for the
<secDNS:update>:

     <complexType name="updateType">
       <choice>
         <element name="add" type="secDNS:dsType"/>
         <element name="chg" type="secDNS:dsType"/>
         <element name="rem" type="secDNS:remType"/>
       </choice>
       <attribute name="urgent" type="boolean" default="false"/>
     </complexType>
 
To allow for a mix of add, chg, and rem, should the XML schema model in the
Domain Mapping (RFC 4931) updateType XML schema definition be used?  I
updated the DNSSEC XML schema below to match the definition of the Domain
Mapping, to support the mix of add, chg, and rem:

      <complexType name="updateType">
       <sequence>
         <element name="add" type="secDNS:dsType" minOccurs=²0² />
         <element name="chg" type="secDNS:dsType" minOccurs=²0² />
         <element name="rem" type="secDNS:remType" minOccurs=²0² />
       </sequence>
       <attribute name="urgent" type="boolean" default="false"/>
     </complexType>
 
Has any of the current implementations come across this issue?

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 9 Dec 2008 12:49:04 -0500

Jim, I think I might have just remembered a use case that makes the
<sequence> a problem.  Imagine if it were possible to create a command
that looks like this:
 
<secDNS:update
   xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
   xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
secDNS-1.0.xsd">
   <secDNS:rem>
     <secDNS:keyTag>12345</secDNS:keyTag>
   </secDNS:rem>
   <secDNS:chg>
     <secDNS:dsData>
       <secDNS:keyTag>12345</secDNS:keyTag>
       <secDNS:alg>3</secDNS:alg>
       <secDNS:digestType>1</secDNS:digestType>
       <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
     </secDNS:dsData>
   </secDNS:chg>
</secDNS:update>
 
Is the server supposed to remove or change the data associated with
keyTag 12345?  With the existing schema there's no ambiguity.

-Scott- 

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of James Gould
	Sent: Tuesday, December 09, 2008 12:04 PM
	To: [email-masked]
	Subject: [ietf-provreg] DNSSEC EPP Extension (RFC 4310)
Usability Question

	In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one
usability issue that I would like to get feedback from the existing
implementations of the extension.  
	
	The specification allows adding (<secDNS:add>), removing
(<secDNS:rem>), and changing (<secDNS:chg>) DS data, but according to
the XML schema they can't be done at the same time.  Below is from the
RFC 4210 XML schema for the <secDNS:update>:

	To allow for a mix of add, chg, and rem, should the XML schema
model in the Domain Mapping (RFC 4931) updateType XML schema definition
be used?  I updated the DNSSEC XML schema below to match the definition
of the Domain Mapping, to support the mix of add, chg, and rem:
	
	      <complexType name="updateType">
	      <sequence>
	        <element name="add" type="secDNS:dsType" minOccurs="0"
/>
	         <element name="chg" type="secDNS:dsType" minOccurs="0"
/>
	         <element name="rem" type="secDNS:remType" minOccurs="0"
/>
	      </sequence>
	      <attribute name="urgent" type="boolean" default="false"/>
	     </complexType>

	-- 

	JG 

	21345 Ridgetop Circle
	LS2-2-1
	Dulles, VA 20166
	
	Notice to Recipient:  This e-mail contains confidential,
proprietary and/or Registry  Sensitive information intended solely for
the recipient and, thus may not be  retransmitted, reproduced or
disclosed without the prior written consent of  VeriSign Naming and
Directory Services.  If you have received  this e-mail message in error,
please notify the sender immediately by  telephone or reply e-mail and
destroy the original message without making a  copy.  Thank you.

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 10 Dec 2008 02:16:41 +0100

James Gould <[email-masked]> 2008-12-09 18:29
> be done at the same time.  Below is from the RFC 4210 XML schema for the

As others have said I think the whole "issue" is the same for all
update operations on various objects, not only DNSkey materials.

I think that by allowing more flexibility with all operations
possible at the same time, it only create confusion with no big
benefit at the end.

Specifically, I think the most frequent use case for DNS material
would be to add *OR* remove a key, and not at the same time if we are
after smooth transitions.
Change of a key detail may be useful but should not happen too often
in practice.

So having only either one add or one chg or one rem block in a
domain:update for DNSkey material seem fine to me, and I would not be
in favor of mixing.

I also observe (without hard numbers) that use cases depend on object
types.
I would say that for status values it seems more logical to have
mainly add and rem operations (and again probably very few with add
and rem together in a single call), where for nameservers the chg
operation may be more frequent (even if not possible by core EPP
RFCs, it is done by some registries).
As for contact, I would say that it derives a lot from the fact that
very few registries seem to allow really multiple contacts of the
same type, and if they do I think very few registrars use that
feature. Hence in that case add or rem operations are probably the
more logical one for contacts during domain update.

For me, no mix at all would be the simpler case, both on registry
side and registrar side: that way there is nothing to think about
what will happen if we do add+rem at the same type for the same info
(otherwise it depends on registry policies and in some case it will
be a noop as add+rem will be seen as opposite, where sometimes in
other registries or other cases it will be a removal since it comes
last), and registrars still have all power to do what they want, they
just, if really needed, do multiple domain:update calls one after the
following and each one with either an add, a rem or a chg. And this
can be encapsulated on their side as a global operation in an higher
API.

I also observe that, for the same object types, some registries allow
*only* chg, others allow *only* add and/or rem and some allow all
3 ... which create even more confusion.

-- 
Patrick Mevzek

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 10 Dec 2008 09:43:16 +0100

> 3 ... which create even more confusion.

Just my two cents: I personally want to have as few calls as possible, so I like 
being able to do additions and removals at the same time. Generally speaking, 
the design question is whether the "add/remove" approach is the preferable 
solution, or whether it is better to choose a "replace all" approach, 
especially, as the number of items (status values, contact reference, IP 
addresses etc.) are rather small. So a client side application would either 
determine the desired state from its own storage and submit it to the registry 
or would query the current state from the registry, alter the state at its own 
discretion and submit it as a whole to the registry. Our experience with such an 
approach in other protocols is rather good, although we discovered the need to 
select which part of the data shall be updated. If one only wants to change the 
name servers of a domain but not the contacts, it could be regarded as a burden 
if the submission of the contact data would be also required.

Regards,

Klaus

---

From: James Gould <[email-masked]>
Date: Thu, 11 Dec 2008 09:59:46 -0500

Patrick,

I disagree with your following paragraph:

It boils down to a transactional consistency issue.  An individual EPP
command is one unit of work and is typically executed as a single database
transaction on the Registry side, so when a Registrar either manages the DS
data for the Registrant or provides a UI for the Registrant to update the DS
data, having to manage the updates in separate commands and subsequently
separate transactions is more complex and will cause transactional
inconsistency.  The only way to keep transactional consistency with the
desire of a Registrant that uses a Registrar¹s UI to manage DS data is to
have the UI only allow either an add, remove, or change, but not a
combination.  I personally have never seen a UI that manages a list in this
manor. 

There is also the issue of transfers.  What happens when a signed domain is
transferred to another Registrar?  Does the DS data transfer along with it
or does it get cleared.  I¹m assuming that it would be transferred along in
a similar model as the name servers.  It is up to the gaining Registrar to
update the name servers and DS data assuming that the hosting is changing
along with the transfer.  In this case, the gaining Registrar would have a
need to remove the existing name servers, add the new name servers, and do
the same with the DS data.  Having this done in separate commands /
transactions would result in DNS getting incremental changes based on the
add and remove order chosen by the Registrar.  It is much cleaner to simply
be able to remove and add in a single command and single transaction, which
will result in one unit of work for DNS updates.

I don¹t believe managing a list with delta adds, removes, and changes is
overly complicated.  The RFC could include text that describes some of the
basic rules to ensure there is consistency.  That assumes that all
Registries fully follow the RFC, which based on your ³EPP : An implementor
experience and recommendations² is doesn¹t look like that is the case.   In
either event, changing the choice to a sequence is backward compatible, so
it should not break current client implementations.  The protocol should
address the most common use cases and ensure transactional consistency.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Patrick Mevzek <[email-masked]>
Organization: Dot And Co
Date: Tue, 9 Dec 2008 20:16:41 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability
Question

--
Patrick Mevzek

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 12 Dec 2008 10:23:25 +0100

On 12/11/2008 03:59 PM, James Gould wrote:
> [...]
>
> There is also the issue of transfers. What happens when a signed domain
> is transferred to another Registrar? Does the DS data transfer along
> with it or does it get cleared. I’m assuming that it would be
> transferred along in a similar model as the name servers. It is up to
> the gaining Registrar to update the name servers and DS data assuming
> that the hosting is changing along with the transfer.
 > [...]

The DS data is not a separate object, but part of the domain object, so there is 
no question that it shall be transferred along with the domain itself. Also it 
is doubtless that the data MAY NOT be cleared.

But this brings me to another question which I have already discussed with 
various people, but with no real satisfying answer yet. Maybe this list is not 
the right place for this question neither, but does the management of the DS 
data via the whole reseller-registrar chain suffice the security needs of the 
DNSSEC infrastructure?

As the name server operator is not necessarily even in this chain, there could 
be weak links, attack vectors that could void the security gained by the DNSSEC 
protocol itself. Shouldn't the name server operator get a separate 
out-of-the-band channel to the registry operator to submit the DS data directly, 
for example with a subset of RFC 4931/RFC 4310? Any comments on this?

Regards,

Klaus

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 12 Dec 2008 10:52:44 +0100

On 12 dec 2008, at 10.23, Klaus Malorny wrote:

> Shouldn't the name server operator get a separate out-of-the-band  
> channel to the registry operator to submit the DS data directly, for  
> example with a subset of RFC 4931/RFC 4310? Any comments on this?

My immediate reaction is "no". There is the same attack vector as  
changes in NS records or glue. I think the DS data should definitely  
follow the same path as other domain related data.

That said, the registry can easily do some checks and balances  
calculation when the data arrive -- before the zone is published. Just  
like they can check glue, that servers are auth etc, they can also  
check the KSK in the child zone that it matches the DS passed to them.

    Patrik

---

From: Klaus Malorny <[email-masked]>
Date: Mon, 22 Dec 2008 15:25:17 +0100

On 18/12/08 16:08, Olafur Gudmundsson wrote:

>> The DS data is not a separate object, but part of the domain object,
>> so there is no question that it shall be transferred along with the
>> domain itself. Also it is doubtless that the data MAY NOT be cleared.
>
> Clearing DS is what you do when child stops using DNSSEC, thus it must
> be allowed.
>

Sure -- I expressed myself unclear. I meant that they should not be cleared as a 
side effect of transfers, as a transfer not necessarily means that the domain is 
moved to a new name server operator and/or to a new set of name servers.

>
> [...]
>
> The important question that registries need to ask them self is
> "Does the DS record in the EPP update the data go into the registry or
> does it only go in if/after the child's DNSKEY RRset has a key that
> matches the DS record?"

A pre-check may reduce the risk of human/machine errors that either make the 
domain unsigned or suggest the domain being compromised. But it seems to me that 
it does not improve security in general.

Thinking a little bit more of my question after your and Patrick's answers, I 
have to admit that it is probably not a good idea -- first, the establishment 
and management of this channel is a problem. If one would not trust the 
registrar/reseller chain enough, this separate channel could not be 
created/maintained using their credibility. However, alternative solutions are 
likely hard to find. Second, name server assignment/host management would need 
to be moved to the name server operators as well. This sounds like a big 
responsibility mess.

Regards,

Klaus

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 25 Dec 2008 04:05:15 +0100

James Gould <[email-masked]> 2008-12-11 18:59
> I disagree with your following paragraph:
 
Ok, I have no strong opinion in either case.

For a recap, we have:
- ns : add and/or rem
- contact : add and/or rem
- status : add and/or rem
- registrant : chg
- authInfo : chg
- secDNS : add and/or rem and/or chg

> inconsistency. 

But this is already the case elsewere then.
For example, for nameservers if you want to *change* them (irrelevant
to what they are now) you need to know the current set to be able to
do a rem and add the correct set. This is one operation, yes. But how
do you know the current set ? Ok, you should be a properly managed
registrar and have a local copy of this information. Even then,
after a transfer for example, you will need a domain:info before your
domain:update, so 2 operations, and even if the domain:info has no
side effect there still could happen many things between the two that
would create transactional inconsistencies.
Also when you speak below about domain transfers currently this means
at least three operations: domain:transfer, domain:info to learn the
new nameservers/contacts and then domain:update. A lot of
inconsistencies can happen there, in part due to the huge number of
related parties for such a case (the registry, the current registrar,
the new registrar, the registrant or admin contact or someone having
pulled the authInfo code from the current registrar to give the new
one, maybe the new hosting company (if != new registrar) and the
old none (if != old registrar), and even we could imagine the key
management authority (if != hosting company), both old and new one...
this is like 10 entities for an operation that could be seen -
depending on the level of where you sit to view it - as a single
operation/transaction ; registrants do view it like that, they do not
understand why a "simple" change of "webhosting" company needs
participation of so many entities with rules to follow, delays to
wait, etc.)

So for me, we should be able to have add *or* rem *or* chg for any
kind of item, but only one of the three in a given domain:update.

> The only way to keep transactional consistency with the
> combination. 

I believe I have said the same things when saying: no mix.

> a similar model as the name servers.

A domain name transfer should have no consequences to the running
state of the domain and its resolution. So, as the name servers are
preserved during a domain name transfer, all related information such
as keys should be preserved too in my mind.

Also, in part because of the problem outlined above, some registries have
extended EPP to permit the specification of new nameservers and/or
contacts when the domain:transfer operation is started, which
basically is identical to a domain:transfer + domain:update without
fear of consistency issues (and if the domaine:update would allow a
domain:ns in the chg node).

It can be seen as a delayed/callback system. The registrar asks for a
domain:transfer (that may succeed or not, immediately or later on)
but ties the success of this operation with some others (change of
nameserves, contacts, etc.) while sending everything in one command
to the registry that will ensure atomicity over the whole set of
changes (either domain:transfer fails without obviously any change or
domainl:transfer succeeds with all changes asked for in nameservers,
contacts, etc.).

>  It is up to the gaining Registrar to
> the same with the DS data.

It has a need to *replace* the current set of nameservers with a new
set. He should be able to do that without even having to know the
current set. Hence the usefulness of the domain:update chg for
nameservers (and same for contacts or statuses) or some registries
extension to do that during the domain:transfer.

>  Having this done in separate commands /
> add and remove order chosen by the Registrar.  

Again, not a problem with a domain:update chg domain:ns or specifying
new nameservers (and key materials but since DNSSEC is not widely
deployed it I've not seen it used the same way in an extended
domain:transfer) directly into the domain:transfer operation.

> It is much cleaner to simply

It believe it is even cleaner to be able to force a new set without
even have to know the previous one.

> experience and recommendations² is doesn¹t look like that is the case.

I believe in this case that we are more touching issues not strictly
technical. EPP with the current behaviour in domain:update is one
point of view, it has merits and drawbacks and other points of view
have other merits and other drawbacks.  But seeing that some
registries did extend it to support other point of view just make me
think that domain:update should be made simpler with my 2 points (add
or rem or chg for any item, and no mix of any of these 3 in any
single domain:update) which would also then accomodate all points of
view.

I do note that domain:update is a very specific case as due to its
nature it is more difficult to properly extend it, and this also
created problems in the past (empty domain:update needed or not in
case of extensions nodes attached to the command).

> In either event, changing the choice to a sequence is backward compatible, so

I think in a previous message I've tried to gather some use cases
that seemed legitimate to me... but it was more a bait than anything
else to make registrars let us know what they do most of the times
and/or registries pull some statistics on this topic based on their
logs :-)

With that data from "true" sources, I believe it would be easier to
see what are the needs and the use cases. We would of course need to
take into account extensions related to this, like I've said above
the fact that registries permit specifying nameservers/contacts
during a domain:transfer, and seeing how it is used by their
registrars.

-- 
Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Sun, 28 Dec 2008 12:35:48 -0500

Patrick,

My point of transactional consistency does not deal with the difference between managing a list via deltas (add and remove) versus a complete set (chg), but deals with the inability to manage a list effectively with either since RFC 4310 does not allow the DS data to be managed using deltas (add AND remove) or a compete set (chg).  Transactional consistency deals with writable operations, where obtaining the current list of name servers, statuses, or contacts from a local datastore or from the Registry is not part of the transaction context.  In my opinion splitting updates across three commands (info, transfer, and update) is fine since info is not part of the transaction context, the transfer is simply a request to change sponsorship of the domain, and the final update should set the domain to the desired state once the transfer is completed and the gaining Registrar is authorized to make the change.  When managing an individual list attribute, being able to do both an add!
  and remove in a single command will allow the list attribute to have a consistent matching state on the Registry side and in DNS.  This seems to me to be simpler and less error prone.  

As far as extensions go, I believe that the ability to add extensions is one of the key features of EPP considering that "E" stands for extensible.  Hopefully the Registries make the extensions as opt ins instead of requirements.  Each Registry has different business models that can be supported by extensions, but the base specifications should continue to hold true.  For example, for .COM and .NET we received feedback from the Registrars that they needed information in EPP that was only available via Whois to support transfers, so we created an extension that would allow them to request it with an info command.  Adding an extension for transfers to do more than change sponsorship when the transfer is completed is not a bad idea as long as its optional.  I believe it is a best practice to incrementally add extensions as opt ins to increase the value to the channel, where some extensions are specific to a Registry and some extensions are more cross-cutting and could be consid!
 ered for a standards track.    

Overall, I believe that the inability to do both an add and remove in RFC 4310 is an oversight that should be addressed to be consistent with the rest of the EPP specifications and to ensure transactional consistency, but I'm not sure if it is bad enough to warrant the process to make the change on its own.  Based on the provreg e-mail list it doesn't look like anyone beliefs that it does warrant a change to RFC 4310 at this point (other than maybe me), so if there is anyone out there that believes that it does please reply to the list.

Thanks,

JG 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Patrick Mevzek
Sent: Wednesday, December 24, 2008 10:05 PM
To: EPP Provreg
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question

For a recap, we have:
- ns : add and/or rem

> command is one unit of work and is typically executed as a single 
> database transaction on the Registry side, so when a Registrar either 
> manages the DS data for the Registrant or provides a UI for the 
> Registrant to update the DS data, having to manage the updates in 
> separate commands and subsequently separate transactions is more 
> complex and will cause transactional inconsistency.

But this is already the case elsewere then.
For example, for nameservers if you want to *change* them (irrelevant to what they are now) you need to know the current set to be able to do a rem and add the correct set. This is one operation, yes. But how do you know the current set ? Ok, you should be a properly managed registrar and have a local copy of this information. Even then, after a transfer for example, you will need a domain:info before your domain:update, so 2 operations, and even if the domain:info has no side effect there still could happen many things between the two that would create transactional inconsistencies.
Also when you speak below about domain transfers currently this means at least three operations: domain:transfer, domain:info to learn the new nameservers/contacts and then domain:update. A lot of inconsistencies can happen there, in part due to the huge number of related parties for such a case (the registry, the current registrar, the new registrar, the registrant or admin contact or someone having pulled the authInfo code from the current registrar to give the new one, maybe the new hosting company (if != new registrar) and the old none (if != old registrar), and even we could imagine the key management authority (if != hosting company), both old and new one...
this is like 10 entities for an operation that could be seen - depending on the level of where you sit to view it - as a single operation/transaction ; registrants do view it like that, they do not understand why a "simple" change of "webhosting" company needs participation of so many entities with rules to follow, delays to wait, etc.)

So for me, we should be able to have add *or* rem *or* chg for any kind of item, but only one of the three in a given domain:update.

> The only way to keep transactional consistency with the desire of a 
> Registrant that uses a Registrar¹s UI to manage DS data is to have the 
> UI only allow either an add, remove, or change, but not a combination.

> There is also the issue of transfers.  What happens when a signed 
> domain is transferred to another Registrar?  Does the DS data transfer 
> along with it or does it get cleared.  I¹m assuming that it would be 
> transferred along in a similar model as the name servers.

A domain name transfer should have no consequences to the running state of the domain and its resolution. So, as the name servers are preserved during a domain name transfer, all related information such as keys should be preserved too in my mind.

Also, in part because of the problem outlined above, some registries have extended EPP to permit the specification of new nameservers and/or contacts when the domain:transfer operation is started, which basically is identical to a domain:transfer + domain:update without fear of consistency issues (and if the domaine:update would allow a domain:ns in the chg node).

It can be seen as a delayed/callback system. The registrar asks for a domain:transfer (that may succeed or not, immediately or later on) but ties the success of this operation with some others (change of nameserves, contacts, etc.) while sending everything in one command to the registry that will ensure atomicity over the whole set of changes (either domain:transfer fails without obviously any change or domainl:transfer succeeds with all changes asked for in nameservers, contacts, etc.).

> update the name servers and DS data assuming that the hosting is 
> changing along with the transfer.  In this case, the gaining Registrar 
> would have a need to remove the existing name servers, add the new 
> name servers, and do the same with the DS data.

It has a need to *replace* the current set of nameservers with a new set. He should be able to do that without even having to know the current set. Hence the usefulness of the domain:update chg for nameservers (and same for contacts or statuses) or some registries extension to do that during the domain:transfer.

>  Having this done in separate commands / transactions would result in 
> DNS getting incremental changes based on the add and remove order 
> chosen by the Registrar.

Again, not a problem with a domain:update chg domain:ns or specifying new nameservers (and key materials but since DNSSEC is not widely deployed it I've not seen it used the same way in an extended
domain:transfer) directly into the domain:transfer operation.

> be able to remove and add in a single command and single transaction, 
> which will result in one unit of work for DNS updates.

It believe it is even cleaner to be able to force a new set without even have to know the previous one.

> I don¹t believe managing a list with delta adds, removes, and changes 
> is overly complicated.  The RFC could include text that describes some 
> of the basic rules to ensure there is consistency.  That assumes that 
> all Registries fully follow the RFC, which based on your ³EPP : An 
> implementor experience and recommendations² is doesn¹t look like that is the case.

I believe in this case that we are more touching issues not strictly technical. EPP with the current behaviour in domain:update is one point of view, it has merits and drawbacks and other points of view have other merits and other drawbacks.  But seeing that some registries did extend it to support other point of view just make me think that domain:update should be made simpler with my 2 points (add or rem or chg for any item, and no mix of any of these 3 in any single domain:update) which would also then accomodate all points of view.

I do note that domain:update is a very specific case as due to its nature it is more difficult to properly extend it, and this also created problems in the past (empty domain:update needed or not in case of extensions nodes attached to the command).

> In either event, changing the choice to a sequence is backward 
> compatible, so it should not break current client implementations.  
> The protocol should address the most common use cases and ensure transactional consistency.

I think in a previous message I've tried to gather some use cases that seemed legitimate to me... but it was more a bait than anything else to make registrars let us know what they do most of the times and/or registries pull some statistics on this topic based on their logs :-)

With that data from "true" sources, I believe it would be easier to see what are the needs and the use cases. We would of course need to take into account extensions related to this, like I've said above the fact that registries permit specifying nameservers/contacts during a domain:transfer, and seeing how it is used by their registrars.

--
Patrick Mevzek

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Dec 2008 09:44:04 -0500

Hi,

On Sun, Dec 28, 2008 at 12:35:48PM -0500, Gould, James wrote:
> 
> Overall, I believe that the inability to do both an add and remove
> in RFC 4310 is an oversight that should be addressed to be
> consistent with the rest of the EPP specifications and to ensure
> transactional consistency, but I'm not sure if it is bad enough to
> warrant the process to make the change on its own.  Based on the
> provreg e-mail list it doesn't look like anyone beliefs that it does
> warrant a change to RFC 4310 at this point (other than maybe me), so
> if there is anyone out there that believes that it does please reply
> to the list.

I think it does, and I'm willing to work on such changes.  I do worry
about the operational effects of performing add and remove at the same
time: it seems to me to be the sort of thing that could take a domain
dark. 

There's an additional issue in this area that's troubling to me, which
has to do with domain transfers in a DNSSEC context, particularly in
cases where the private keys for the two sponsors can't be shared
(imagine the case where the two sponsors are each involved in
operating the DNS for the target domain; in this case, they're not
going to share private keys with one another).  It seems to me that in
such a case, a sponsor needs to be able to add a DS record to a domain
object when the sponsor doesn't actually own the domain.  This is
problematic, because obviously we don't want random others being able
to add properties to the objects one sponsors.  It would be possible
to allow this while a transfer is pending, but often there are various
prohibitions on such a domain, and perhaps those will conflict with
the ability of the gaining sponsor to add properties to the
prospectively-transferred domain.  Thoughts?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 29 Dec 2008 10:31:24 -0500

>prospectively-transferred domain.  Thoughts?

What do you mean by "the private keys for the two sponsors?"

Splitting hairs, the signing of DNS information happens after it 
leaves the database (of the registry) and before it hits what is 
currently known as the DNS (the master server).  If a registrant has 
two operators for DNS (and many do), the operators are either both 
offering slave service or one is slaving off the other.

IOW, if there are two sources of key-pairs for a domain name, there's 
trouble elsewhere.

Maybe I don't understand the situation you have in mind.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Dec 2008 13:10:42 -0500

On Mon, Dec 29, 2008 at 10:31:24AM -0500, Edward Lewis wrote:

> Splitting hairs, the signing of DNS information happens after it leaves 
> the database (of the registry) and before it hits what is currently known 
> as the DNS (the master server).  If a registrant has two operators for 
> DNS (and many do), the operators are either both offering slave service 
> or one is slaving off the other.
>

Suppose I have RegA and RegB, and a registrant with example.org
sponsored by RegA.  RegA also happens to be the DNS operator for
example.org.  Example.org is signed.

If the registrant wants to move to RegB, there's a potential problem.
RegA operates the DNS, and therefore presumably has the private keys
for the current keying material corresponding to the DS record in
.org.  There are a few possibilities I've thought of (in no particular
order): 

1.  Create new keys, publish them in RegA's DNS and as the DS in the
.org DNS, and then use those keys for RegB's DNS as well.  This
requires the registrant to know something about DNS, I expect, and
also requires RegA to present an interface for registrant to send the
key information (and RegA may not have such an interface).

2.  Get RegA to give the private key data to RegB.  This is a bad idea
anyway, and anyway I doubt anyone would co-operate with it.

3.  Co-ordinate the operation (independently) between RegA and RegB.
This requires that every DNSSEC-operating registrar in every registry
have some sort of bilateral communication with every other registrar.
I doubt this will work.

4.  Make it possible for RegB to modify the DNS data of the domain
while the domain is pending transfer.  This strikes me as a very
EPP-like way to do it: the gaining client initiated the transfer, then
sends the update command with the new name servers and key data to the
registry.  The domain is in pendingUpdate _and_ pendingTransfer status
until the transfer is approved, at which point the updates
automatically happen.  If the transfer is refused, then the update
fails as well.  I _think_ this is compatible with the current RFCs,
but I'm not aware of any currently deployed code that works this way.

5.  Go through an insecure phase

6.  RegB obtains the necessary (public) key data from RegA and
publishes all of it in the RegB DNS.  By carefully sequencing the
addition of additional records and removal of old ones, the domain
remains secure the whole time.  This can be made to work today, but I
think it's a little fragile.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.