Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-dnssec-dps-framework-02

From: Antoin Verschuren <[email-masked]>
Date: Wed, 13 Oct 2010 22:47:06 +0200

Op donderdag 30-09-2010 om 16:39 uur [tijdzone +0100], schreef Stephen
Morris:
> 
> The working group adopted the draft last year but since then there has been little discussion of it on the list.  With DNSSEC at last looking as if it is really starting to take off, this is a timely document.  Please have a look at it and give feedback.

We have used the draft dps framework to write down our DPS when we
introduced DNSSEC for .nl.
We are currently rewriting our DPS to include DS/DNSKEY submission into
our zone, and we encountered a missing comunity in the outline in
section 5. In our DPS, we are defining a dns-operator as an entity that
needs to be defined seperately from an administrative
registry/registrar/registrant definition as sugested in the outline. I
would strongly suggest to include a technical dns-operator definition in
the outline, so that section 3 of the outline will be:
1.3.  Community and Applicability
          1.3.1.  Registry
          1.3.2.  Registrar
          1.3.3.  Registrant
          1.3.4.  Zone maintainer
          1.3.5.  Relying Party
          1.3.6.  Auditor
          1.3.7.  Applicability
We're still in discussion if we need to separate zone operator (only running the DNS server infrastructure) and zone maintainer (who is able to change the zone's content), or that we can come up with a definition that clearly defines the entity that is controlling the access to the zone, and can insert RR's and reload the zone when necessary for DNSSEC maintenance.
My personal opinion is that we need to define an entity that can add/remove/change DNSKEY RR's and can push the button to resign the zone, and when he does, can communicate that to the parent zone through registrar, registrant, registry or any combination of those.

-- 
Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: Fredrik Ljunggren <[email-masked]>
Date: Thu, 14 Oct 2010 09:42:48 +0200

Antoin,

Isn't the Zone Maintainer (DNS operator) really just a delegate of the registrant and not a separate role? The registrants should be in control of their domain name and responsible for managing the keys.

However, many (but certainly not all) may delegate or outsource the function of operating the DNS server to an external party, and maybe also signing.

It is probably just a matter of how you look at the relations. I think introducing the DNS operator as a separate entity complicates matters in many cases. Can you give an example where the DNS operations can not fall within the registrants responsibility?

If there are circumstances that require this role to be defined, it is also perfectly fine to add that as a subcomponent of the registrant while still being in full compliance with the framework.

-- Fredrik

On 2010-10-13, at 22:47, Antoin Verschuren wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Fredrik Ljunggren <[email-masked]>
Date: Thu, 14 Oct 2010 11:07:08 +0200

Stephen,

Thanks for all your edits. I've implemented almost all of them. There are a few remaining which I'd like to discuss with you, I'll send that to you privately. And I'll make sure to submit a new version before Oct 25.

I do see your concerns regarding 4.8 (Legal Matters), and that this may be out of scope for some, or even most drafters of DPSs. I think we are quite clear that we do not provide any legal advice here. However, I do have seen the need for clarifying the legal status of the DPS and also to provide references to other agreements. This is where we need this section. Those not in need of the legal section are completely free to leave it without any stipulation, while still being in compliance with the framework.

On the other hand, I think all of Section 4.4 (Facility, Management and Operational Controls) is central for being able to evaluate the level on confidence one can put into the operator function. Moving into a DNSSEC signed zone also puts more pressure onto the contingency planning. I agree that the organization "should" have all this in place (and in those cases, it will be very easy to disclose what is being done), but we all know this may not always be the case and (IMHO) can't be left as an assumption.

So I would suggest we keep those sections and remember that everything that a drafter considers to be out of scope in respect to his/hers situation can be left without stipulation.

regards,

 -- Fredrik

On 2010-09-30, at 17:39, Stephen Morris wrote:

> (Hat off)
> 
> I've had a look at draft-ietf-dnsop-dnssec-dps-framework-02 and have the following main comments:
> 
> Section 4.4 Facility, Management and Operational Controls
> There is a lot in here about disaster recovery planning that an organisation should already have documented.  Ought this document simply concentrate on the DNSSEC aspects and just assume that such plans exist?
> 
> Section 4.8, Legal Matters
> I can't help feeling that the section goes well beyond the scope of what should be in a DNSSEC policy statement.  A lot of this would be applicable to any contract between two parties, so does it really belong in this draft?
> 
> There were a number of other issues about phrasing and typos - I have sent those directly to the editors.
> 
> (Hat on)
> 
> Stephen

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 14 Oct 2010 18:08:59 +0200

Op donderdag 14-10-2010 om 09:42 uur [tijdzone +0200], schreef Fredrik
> Isn't the Zone Maintainer (DNS operator) really just a delegate of the registrant and not a separate role? The registrants should be in control of their domain name and responsible for managing the…

In the administrative Registry-registrar-registrant contractual model,
you're absolutely right

> However, many (but certainly not all) may delegate or outsource the function of operating the DNS server to an external party, and maybe also signing.

And the error that is often made is the wrong assumption that the
registrar by definition the only technical dns-operator that the
function is outsourced to.

> It is probably just a matter of how you look at the relations. I think introducing the DNS operator as a separate entity complicates matters in many cases. Can you give an example where the DNS ope…

It's not about giving the DNS-operator a role in the administrative
contractual relationship between registry-registrar-reseller-registrant.
But if we define a resolver operator (1.3.4.  Relying Party) as an
entity that is affected by DNSSEC, then we should also state that
authoritative DNS operators are affected by DNSSEC, and explain what
their role is in the process.

> If there are circumstances that require this role to be defined, it is also perfectly fine to add that as a subcomponent of the registrant while still being in full compliance with the framework.

The dns-operator is needed for a number of registry processes where a
change of dns-operator for the authoritative nameservers for a child
zone happen. This MAY be (but not necessarily):
-domain transfers (changing registrar)
-domain hand-overs (changing registrant)
-nameserver changes
-turning DNSSEC on/off
In these cases, we want to describe what the role of
registry-registrar-registrant is, and who should do what.
In case of describing the responsibilities of the registrant, we want to
state that he is responsible for zone maintenance, including key
maintenance, even if he outsources that to a 3th party dns-operator.
To be able to state what a registrant should do, and how things work, we
cannot do without defining what a registrant can outsource to a
dns-operator, and what a registrant should be aware of when entering in
such a bilateral contract with a dns-operator. What contractual
responsibilities he transfers when he does not control the zone himself.

-- 
Antoin Verschuren

---

From: Richard Lamb <[email-masked]>
Date: Thu, 14 Oct 2010 13:10:22 -0700

IMHO since the DPS is the only public document , section 4.4 and its DR aspects should be in the DPS to at least indicate to the public that these issues have been considered.

4.8 ought to be there as an optional reminder for those writing such a framework.

-Rick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stephen Morris
> Sent: Thursday, September 30, 2010 11:39 AM
> To: [email-masked]
> Subject: [DNSOP] Comments on draft-ietf-dnsop-dnssec-dps-framework-02
> 
> (Hat off)
> 
> There is a lot in here about disaster recovery planning that an
> organisation should already have documented.  Ought this document
> simply concentrate on the DNSSEC aspects and just assume that such
> plans exist?
> 
> I can't help feeling that the section goes well beyond the scope of
> what should be in a DNSSEC policy statement.  A lot of this would be
> applicable to any contract between two parties, so does it really
> belong in this draft?
> 
> The working group adopted the draft last year but since then there has
> been little discussion of it on the list.  With DNSSEC at last looking
> as if it is really starting to take off, this is a timely document.
> Please have a look at it and give feedback.
> 
> Stephen

---

From: Fredrik Ljunggren <[email-masked]>
Date: Fri, 15 Oct 2010 10:46:33 +0200

> -domain hand-overs (changing registrant)

As I see it, this is the sole responsibility of the registrar, having outsourced the DNS operator function or not.

> responsibilities he transfers when he does not control the zone himself.

Walking down that path, it seems to me we can define an infinite number of parties under section 1.3, and we can't really do that in the framework. I suggest we either strike 1.3.1 -> 1.3.6 from the outline in section 5 all together, and leave that to the discretion of the DPS author, or just leave it as it is with the general roles from the registry-registrar-registrant model.

I'm leaning towards striking them out, but I'd like to hear what others have to say.

-- Fredrik

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 15 Oct 2010 16:57:36 +0200

Op vrijdag 15-10-2010 om 10:46 uur [tijdzone +0200], schreef Fredrik
> As I see it, this is the sole responsibility of the registrar, having outsourced the DNS operator function or not.

And here you make the famous error of mixing up the model with praxis,
that is if you didn't make a typing error and really meant registrANT.

It's the registrant that is the owner of the zone data, and if he
outsources to a third party dns-operator, he remains responsible for his
zone data. He needs to realize this when outsourcing to a 3th party
dns-operator, and that is why I want to define what a dns-operator's
role is.

The fact that in practice the registrant often outsources his
dns-operations to the same entity that also functions as registrar does
not change the model.

The problem is that there is an administrative contractual relationship
between the registry and the registrar what administrative procedures
are concerned, but there is no relationship between the registry and the
registrar in it's function as 3th party dns-operator. That relationship
is purely a bilateral agreement between the registrar and registrant,
with no influence in terms of policy from the registry on that
relationship. That is because the registrant is free to run his own
dns-operations or outsource to a completely different 3th party
dns-operator, not being a registrar.

-- 
Antoin Verschuren

---

From: Fredrik Ljunggren <[email-masked]>
Date: Fri, 15 Oct 2010 18:38:08 +0200

> that is if you didn't make a typing error and really meant registrANT.

Yes, ofcourse. I did mean _registrant_! ;-)

-- Fredrik

---

From: Anne-Marie Eklund-Löwinder <[email-masked]>
Date: Sat, 16 Oct 2010 02:03:09 +0200

I'm glad you did sort that out:).

/amel

> -----Ursprungligt meddelande-----
> Från: [email-masked] [mailto:[email-masked]] För
> Fredrik Ljunggren
> Skickat: den 15 oktober 2010 18:38
> Till: Antoin Verschuren
> Kopia: <[email-masked]>
> Ämne: Re: [DNSOP] Comments on draft-ietf-dnsop-dnssec-dps-framework-02
>
>
>
> >> As I see it, this is the sole responsibility of the registrar,
> having outsourced the DNS operator function or not.
> >