Subject: [DNSOP] CDS RRtype - automated KSK rollover

From: "George Barwood" <[email-masked]>
Date: Sun, 12 Jun 2011 20:50:49 +0100

I have updated the draft

http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-02.txt

I have added an appendix with an exampler KSK rollover, and made
various generally minor changes.

IANA have now assigned type code 59 for the CDS RRtype.

I'd like to request that the WG adopt this document.

George

---

From: Stephen Morris <[email-masked]>
Date: Thu, 30 Jun 2011 15:32:10 +0100

> I'd like to request that the WG adopt this document.

Before calling for adoption of this draft or any other similar proposal,
I think we should step back a minute and take a look at the context.

There was quite a discussion on the subject of "automatic update of DS
records" in this mailing list during February and March last year (the
thread started by Tony Finch at at
http://www.ietf.org/mail-archive/web/dnsop/current/msg08079.html).
Early on in the discussion, Ed Lewis said:

"My concern - if the IETF produces a solution for transferring DS
records in-band to the DNS protocol we will repeat a mistake made in
pushing EPP to Full Standard. Pushing EPP to Full Standard is in itself
a true accomplishment and there is no controversy, the process was
followed faithfully. The problem is, once it was Full Standard it was
found to not be applicable to the general population that it was
designed to serve. The protocol works and is interoperable; the
requirements didn't grow as the use cases grew."

I agree with Ed and think that we before adopting a solution, we
should step back and ask some basic questions such as:

1. Is there a problem?
2. If so, do we agree on the nature of the problem?
3. If we agree, is the IETF (and in particular, DNSOP) the place to
develop a solution?

Last year's discussion thread covered a number of issues: at the risk of
missing ones and losing some of the nuances of the discussion, the ones
that stood out when I reviewed it were:

* Do we need to automatically update DS records?
Current manual procedures were cited as being error-prone (i.e. people
are less likely to notice a mistake in cutting and pasting a DS record
into a web form than doing the same with an NS record), and there was
the suggestion that DS records are likely to need more frequent updating
than NS records.

* Who is the target audience?
Should the operator/registrant-registrar-registry ecosystem be the
primary or only target audience or should this approach focus on other
parent/child relationships?

* How should we update DS records?
There was some discussion as to whether the update channel should be
from child zone to parent zone, or whether the update should go through
the registrant->registrar->registry path (or variation thereof). With
the latter, EPP was suggested.

* If we automatically update DS records, why not NS records?
Delegations are frequently broken - if we have a mechanism for
automatically updating DS records, can we use the same mechanism to
update NS records as well?

* What sort of security issues will arise?
If you use an in-band (i.e. DNS) solution to transfer information from
the child to the parent, how does it cope if the child zone has been
compromised?

* What sort of out-of-band communication should exist between parent and
child zones?
It was felt that some form of non-DNS communication needs to exist
between the operators of the parent and child zones to handle initial
zone configuration and to resolve emergencies and the like.

* Does this raise any issues with regards to transferring secure domains
between registrars?
The problems associated with these types of transfers have been
discussed to great extent elsewhere, but they may have a bearing on the
solution.

So it seems to me that the first step would be to write a draft that
defines the problem and the requirements for a solution. (The
requirements should include real-world requirements, e.g. how do we
assess the potential bypassing of a registrar in changing registry
data?) Solutions can then be measured against that.

Does this sound a reasonable way for the WG to proceed?

Stephen

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 30 Jun 2011 16:42:11 +0200

> * Does this raise any issues with regards to transferring secure domains

There isn't any issue transfering secure domains between registrars.
There might only be an issue transfering domains between dns-operators.

- -- 
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: Olafur Gudmundsson <[email-masked]>
Date: Thu, 30 Jun 2011 12:30:37 -0400

>> http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-02.txt
.....
> should step back and ask some basic questions such as:

Yes there is a problem

> 2. If so, do we agree on the nature of the problem?

The overall issue is that child knows what KSK's it wants to use,
but the parent publishes what that as DS, getting the information from 
the child to the parent is the problem.

There are multiple possible paths for the information:

EPP: Only works when there is a EPP path from the child to the	parent 
but natural in the RRR (Registry/Registrar/Registrant) world when the 
DNS operator has access to the Registrar.
Note in the RRR world the parent can be either Registry or Registrar.

Dynamic update: only works if parent is willing to GRANT child the right 
to update the DS set.

Web interface: child needs login credentials

Vendor supplied solution: if a distributed organization uses single 
solution DNS vendor that product can perform this work w/o any 
standardization.

Parent scans DNSKEY: does not work for all possible KSK rollovers i.e. 
algorithm removal, and if the parent scans at the wrong time, there 
might be validation error due to timing.

Child sends via email: needs authentication, scaling issues

Child publishes in zone what it wants parent to publish: GB proposal

> 3. If we agree, is the IETF (and in particular, DNSOP) the place to

Not sure there is a "proper" home for this work anywhere right now nor a 
wrong place, dnsop is probably a better place for now as the possible 
output of this process are BCP's as how to do things for each of the 
possible channels.

> the suggestion that DS records are likely to need more frequent updating

It would be nice, and make the system more robust. FWIW I think NS can 
be automatically maintained after we have DNSSEC by having the parent 
copy what the child publishes.
So maybe we should be having a different discussion:
Does DNSSEC obsolete updating NS and DS information via EPP/Web/Email ?
In the ICANN version of the RRR the path from can quite easily be:
DNS Operator --> Registrant --> Reseller --> Registrar --> Registry
how many of these links are automated ?
does it make sense for all of them to be involved ?

> parent/child relationships?

I have many burns on my body from using the RRR word incorrectly, and 
many people do not have the full model of roles and responsibilities for 
each role.
my suggestion is to describe the process between parent and child
and then map the process onto the different operating models.

> the latter, EPP was suggested.

As I explained above there is NO one solution

> update NS records as well?

yes and the discussion should be about consistency of information in 
parent and child with the child as the source.

> the child to the parent, how does it cope if the child zone has been

Is this any worse than if the web account is compromised?
Account is reset, information submitted via account overwrites what is 
in the DNS.
I propose that DNSSEC be the precondition.

> zone configuration and to resolve emergencies and the like.

No one solution fits all possible.
But in general initial configuration MUST take place outside DNS.

> discussed to great extent elsewhere, but they may have a bearing on the

Not an issue at all with registrar transfer, if you on the other hand
had said DNS Operators
then in general parent zone must be able to merge two DS sets before the 
transfer and after transfer to switch only the DS for the new operator.

> data?) Solutions can then be measured against that.

Do I read this statement you want a requirements that only support the 
RRR model ?

> Does this sound a reasonable way for the WG to proceed?

Yes,

Olafur

---

From: Stephen Morris <[email-masked]>
Date: Thu, 30 Jun 2011 17:56:40 +0100

> Do I read this statement you want a requirements that only support the

No.  It was only an example and not intended to restrict the scope of
the requirements in any way.

Stephen

---

From: "George Barwood" <[email-masked]>
Date: Thu, 30 Jun 2011 23:33:57 +0100

----- Original Message ----- 
From: "Stephen Morris" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 30, 2011 3:32 PM
Subject: Re: [DNSOP] CDS RRtype - automated KSK rollover

> http://www.ietf.org/mail-archive/web/dnsop/current/msg08079.html).

I'd like to also reference this thread

http://www.ietf.org/mail-archive/web/dnsop/current/msg08424.html

which references an earlier requirements document from 2004, that is

http://tools.ietf.org/html/draft-ietf-dnsop-key-rollover-requirements-02

I think that requirements document is reasonably clear, and I think the earlier thread
indicates a reasonable consensus to move forward with satisfying the requirements.

> parent/child relationships?

I believe it's best to leave out discussion of registrars etc, because I think the problem
can be properly solved and standardised in a generalised parent/child model.
> the child to the parent, how does it cope if the child zone has been

Well if the child zone ( the secret keys, I assume you mean) are compromised then all
security is lost in any case, and I'm not sure much more can be said.
Maybe I'm missing some subtlety here.
 
> zone configuration and to resolve emergencies and the like.

That's true. In general it's necessary to have an out-of-band bootstrap
mechanism for initial configuration and for reset if the child private keys are lost.
That said, it may be possible to have "insecure/opportunistic" auto-configuration 
in situations where the child has responsibility to verify the parent data.
I leave that open in the draft by saying it is parent policy :

  If the result is insecure, extra checks MAY be performed
  according to the parent zone policy.

> discussed to great extent elsewhere, but they may have a bearing on the

I think that is a distinct issue, although a general in-band mechanism to update
the parent DS RRset may well be useful in that situation. In the draft I focus
mainly on key rollover, but algorithm rollover is of course also covered, and
any other situations that require changes to the parent DS RRset.

> Does this sound a reasonable way for the WG to proceed?

Is the earlier requirements draft from 2005 (linked above) substantially incomplete in some way?
I think that would be a reasonable basis to measure, I would claim that the CDS
record is capable of satisfying the requirements expressed there in a natural way. 
I also think the requirement is actually fairly clear - when implementing KSK rollover,
you reach a point where it's clear that something is needed ( other than asking
the operator to start cutting and pasting / interfacing with some out-of-band system / whatever).
I doubt another cycle of requirements would be productive - we might be here again in 6 years time!

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