Subject: Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt

From: Matthijs Mekking <[email-masked]>
Date: Mon, 01 Jul 2013 15:25:10 +0200

Hi Olafur,

On 06/28/2013 08:18 PM, Olafur Gudmundsson wrote:
> 
> On Jun 25, 2013, at 6:05 AM, Matthijs Mekking <[email-masked]> wrote:
> 
>> Hi,
>>
>> On 06/21/2013 11:58 PM, Wes Hardaker wrote:
>>> Paul Wouters <[email-masked]> writes:
>>>
>>>> I am in favour of adopting this draft as a WG item.
>>>
>>> Ditto.
>>
>> Another ditto. I am pleased to see that there is still activity on the
>> topic of automating the synchronization between DNSKEY at the child and
>> the DS at the parent.
>>
>>
> Thanks
> 
>>>> I don't think the CDS record should be able to cause a child domain to
>>>> go from secure to insecure, or from insecure to secure. That
>>>> (infrequent) change should have an additional authentication, eg via EPP
>>>> or otherwise)
>>>
>>> Ditto.  I think the goal of any of the automatic update techniques
>>> should be to make the routine easy but it shouldn't be a goal to handle
>>> the infrequent, and challenging cases.  (infrequent and easy is fine).
>>>
>>> Unless we can show a clear, secured, path for some transition I don't
>>> think it's worth solving.
>>
>> Another ditto. Agreeing with it's not worth solving to deal with the
>> irregular cases. Going unsigned is an irregular case.
>>
>>
>> Also backing a previous made comment by other people:
>>
>> * I prefer to have the CDS wire format to be similar to the DS wire
>> format. With the current draft, it is already possible to automate all
>> possible key rollovers, no need for managerial hooks to say this record
>> is proposed, must be added, deleted, is valid for only this period etc.
>>
>>
> 
>> Comments on the draft (apologies for its length):
> 
> Thanks for the comments. 
> 
>>
>> * Nit: In section 1, it says there may be two interactions with the
>> parent. This could also be only one, this could be more in some freaky
>> rollovers, so I would prefer that it reads: "there may be one ore more
>> interactions with the parent".
> 
> Applied 
> 
>>
>> * Section 3. I appreciate that most ZSK /KSK terminology is carefully
>> replaced with, but in section 3 is still something that itches: "The SEP
>> bit is an optional bit to indicate that the key is allowed to sign the
>> DNSKEY RRset". That is not true. Without the SEP bit, the key may also
>> sign the DNSKEY RRset.
>>
> 
> I agree but still want to bring up the SEP bit, 
> would some thing like this be better: 
> "The SEP bit is an optional bit that indicates that the child expects to sign the
> DNSKEY RRset with that key, while the key is in use." 

This text is better. Still, I want to propose text:

"The SEP bit, if set, indicates that the DNSKEY is intended for use as a
secure entry point, thus are used to sign the DNSKEY RRset, and the
Parental Agent can calculate DS records based on that."

This removes the notion of optional (strictly the bit is not optional,
the setting of it is).

>> * Section 3.1.1. As said above, I don't like the idea of using the CDS
>> record to go unsigned.
>>
> 
> Ack, 
> this is going to be a design point allow or not allow this function. 
> We can remove this part and later propose it as part of an extension, just like 
> any protocol to automate the tickling of the parent. 
>  
>> * Nit: Section 4.1. I think the last paragraph fits better in section
>> 4.2. CDS Consumption.
> 
> Reworked both sections to address this 
>>
>> * Section 4.2. About the polling strategy. I am wondering how well this
>> scales with respect to the number of delegations.
> 
> The next version will indicate that polling has scaling issues, but punt the problem of 
> defining a mechanishm to another document. 
> The thinking is the "parental notification" is the HARDEST part of the proposal, 
> and we might need multiple solutions depending number of delegations and other factors. 
> Having said that in many cases in particular the enterprise and university cases polling is perfectly fine 
> and will scale, thus our thinking is we will document that and start a parallel document on "MAGIC" system 
> that does the notification, along the lines you documented few years back. 
> 
>>
>> * Section 4.2. It is suggested that RFC 5011-like hold down timers are
>> being used, e.g. new keying information must be published for a month
>> before acceptance as a new trust anchor. This makes the duration of key
>> rollovers unnecessary long. The hold down timers in RFC 5011 are there
>> to mitigate against a compromise. The compromise allows the attacker to
>> sign data in the zone.
> 
> I hear you and want other people to chime in, both in the context of 
> compromise and time to perform rollover. If rollover is done by 
> automated systems that perform checks before progressing who cares how long the 
> rollover takes? 

It depends on what you gain with the long wait. I said in my e-mail that
for me it makes sense to do hold down timers in the RFC5011 case, but we
don't need to be that conservative with CDS. But I guess it has to do
with local policy, what checks you require.

I don't have very strong feelings about this. I just want to see it as
fast as possible:). I guess if everything is done automagically, this is
less of a pain.

A nit drawback I see is that during the transition period you have to
deal with a larger DNSKEY and/or DS RRset.

>>
>> Similar we could look at a compromise that allows the attacker to upload
>> a DS/DNSKEY to the parent. However, there are no mechanisms to mitigate
>> against this attack. Why should we have mitigation for the CDS proposal,
>> if there is none for the current mechanism?
>>
>> The difference between CDS and RFC 5011 is the location of the trust
>> anchor your are updating. With CDS, you are updating the DS in the
>> parent. With RFC 5011, you are updating lots of trust anchors in the
>> wild. The latter may indeed require a bit more conservative approach.
>>
>> * Section 4.3. I wonder if the SHOULD in the first sentence should be a
>> MUST.
>>
> I think a better way is to encourage the child to ONLY publish CDS when there is a need to change the DS record and
> remove after parents performs change. 

I prefer the approach where the CDS represents what DS should be in the
parent. You can make checks: if it is the same, we are in sync. If not,
the parental agent still has work to do.

Adding behavior to remove the CDS again after the update has taken place
at all parent name servers, makes the usage at the child unnecessary
complex.

>> * Section 4.4. I dislike the idea of the side effect of parent
>> calculates DS, so I would like to see that only the "augment" mode is
>> supported (where I think it should read: "it will make sure there are
>> CDS records for the digest algorithm(s) it require(s)" (CDS instead of
>> DS)).
>>
> 
> You are not alone, but there are some people in your neighborhood that 
> feel strongly the other way and argued strongly against version 01 because 
> this was outlawed. 

Hm, yes. And I remember that they require the DNSKEY too. Still, I would
still like to see that the CDS should match the "to be calculated DS".

>> The publishing "Future DNSKEYs" does not go well with several rollover
>> scenarios (those based on Double-DS). I am wondering if the policy is
>> "We calculate the DS" or "We decide the digest algorithm". In case of
>> the latter, then augment mode can be used to support this. In case of
>> the first, the future DNSKEY is really required to be published, and
>> Double-DS based rollovers are not possible in combination with CDS.
>>
> 
> exactly 
> 
>> * Section 6. Security Considerations. The last paragraph. Isn't this
>> solved by saying that the Parental Agent MUST ensure that old versions
>> of the CDS RRset do not override newer versions in section 4.3. Usage?
>> There is already a proposed method on how to achieve this there.
>>
> 
> Strictly speaking using RFC5011 will address this as all the signatures in 
> "disjoint" authorative servers wil have expired. 

>> * When implementing a prototype for this in OpenDNSSEC, I questioned
>> myself what value I should use for the TTL. We could consider 0, as this
>> record is not really intended for the resolver. We could also use the
>> TTL to suggest a polling frequency for the parental agent. Just some
>> thoughts.
>>
>>
> I had not thought about guidance on the CDS TTL, nor on the signature lifetime on the record. 
> You have any ideas? 

I just set it to the DNSKEY TTL currently. In OpenDNSSEC you can only
set different signature lifetime for NSEC(3) and the rest, so nothing
special there for CDS either.

I don't think we need special guidance.

The only idea I had, I already mentioned is that we could use the TTL
field to signal a polling frequency.

Best regards,
  Matthijs

>> Best regards,
>>  Matthijs
> Thanks for great review. 
> 	Olafur

---

From: Warren Kumari <[email-masked]>
Date: Mon, 1 Jul 2013 09:52:03 -0400

On Jun 17, 2013, at 1:32 PM, Warren Kumari <[email-masked]> wrote:

> Hi there all,
> 
> We have just posted a new version of draft-kumari-ogud-dnsop-cds 
> 
> This incorporates comments from both the list and in person discussions. 
> 
> The authors believe this version is ready for WG adoption and request the DNSOP chairs to kick off an adoption call.

It has now been 2 weeks since we requested a call for adoption on this. 
Chairs?

W

> 
> W
> 
> 
> Begin forwarded message:
> 
>> From: [email-masked]
>> Subject: New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
>> Date: June 17, 2013 12:58:29 PM EDT
>> To: Olafur Gudmundsson <[email-masked]>, Warren Kumari <[email-masked]>, George Barwood <[email-masked]>
>> 
>> 
>> A new version of I-D, draft-kumari-ogud-dnsop-cds-02.txt
>> has been successfully submitted by Warren Kumari and posted to the
>> IETF repository.
>> 
>> Filename:	 draft-kumari-ogud-dnsop-cds
>> Revision:	 02
>> Title:		 Automating DNSSEC delegation trust maintenance
>> Creation date:	 2013-06-17
>> Group:		 Individual Submission
>> Number of pages: 14
>> URL:             http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-02.txt
>> Status:          http://datatracker.ietf.org/doc/draft-kumari-ogud-dnsop-cds
>> Htmlized:        http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-02
>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-kumari-ogud-dnsop-cds-02
>> 
>> Abstract:
>>  This document describes a method to allow DNS operators to more
>>  easily update DNSSEC Key Signing Keys using DNS as communication
>>  channel.  This document does not address the initial configuration of
>>  trust anchors for a domain.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>> 
> 
> --
> "Let's just say that if complete and utter chaos was lightning, he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'."
> 
>    -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of Magic)
> 
> 

--
Hope is not a strategy.
      --  Ben Treynor, Google

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 1 Jul 2013 15:16:50 +0000

I have read both draft-hardaker-dnsop-csync-00.txt as draft-kumari-ogud-dnsop-cds-02.txt, and I must say I have a preference for the more general approach of draft-hardaker-dnsop-csync-00.txt.
Both documents try to accomplish the same, but draft-kumari-ogud-dnsop-cds-02.txt only tries to do so for one specific use case, and it seems it's trying to write the problem statement after presenting the sollution.

I esspecially don't agree with the text in paragraphs 1.2, 2.1, 2.2 and 2.4 of draft-kumari-ogud-dnsop-cds-02.txt.
They seem to focus only to how registrations and the RRR model is percieved, focusses esspecially on the GTLD space, but fails to give a clear definition.
With most registries, a registrant does not "buy" a domain. it may be percieved as such, but when it is not renewed in the GTLD case, you don't own it anymore, which I don't see as "buying".
In other TLD's, delegations are based on licenses, or in many cases, there is a direct contractual relationship between a regisry and registrant.
I would say to not focus on trying to translate what we see in our own experience, but try to find a good definition, if one is needed at all.
I would like to see a definition that fits all models, be it a TLD or another parent. Lets make it more general.
I would formulate a definition like this:

Registry: Entity that is responsible for a parent zone that maintains registrations of delegations in that zone.
Registrant: Entity that is responsible for a child zone that was delegated to him by a parent.
Registrar: Administrative entity that represents the parent towards a registrant for administrative maintanance of the registration data of the delegation at the parent.

Let's try to forget everyones personal  frustration with all of the examples we know.

The use case we're trying to solve is how to get data from child to parent that needs to be part of the delegation.
I think we need to make clear that there is a difference between administrative and technical data.
Technical data usually flows over the administrative channel because a delegation needs bootstrapping, and no delegation yet excists, so no secure channel is available.
When we want technical data to flow over DNS from child to parent after bootstrapping, I don't see a difference between DS, DNSKEY, NS or other other technical data.
That's why I like draft-hardaker-dnsop-csync-00.txt better, because that's the general use case.

In the general use case, we don't need to think on DS versus DNSKEY, SEP bit set or not, etc.
You just publish technical data for the parent to notice.

The question I'm still puzzled with in both proposals is how we're going to migrate from the current "pushing technical data to the parent over the administrative channel" towards "pushing technical data over the DNS for the parent to pick up". I actually think that this is not as easy as we think, and we're sticking our heads in the sand if we say this is "local policy". We allways want the administrative channel to be a back-up channel when the delegation breaks, and we need to re-bootstrap the delegation. But this leads to the question which path is authoritative. In simple words, what do I do as a parent (or parental agent) when I recieve information over the DNS that conflicts with data I receive over the administrative channel. Which data should I follow.

Some remarks to earlier discussions I saw here on the list:
It was stated that when a parent is requesting DNSKEY instead of DS, and the parent calculates the DS, the disadvantage is that the child cannot choose the digest algorithm. This is not true. The child can send the DNSKEY and signal the desired algorithm by which the parent should calculate the digest. The parent may limit the number of algorithms to choose from, but that does not mean there is no choice. The parent may have good reasons to limit the number of digest algorithms. I don't want to go into too much discussion on the DS versus DNSKEY acceptance by the parent, but we recently found another issue in provisioning that we could not have solved easily if we as parent only knew the DS.

The second remark I have is that the only use case that seems to favour DS over DNSKEY is standby keys where you don't want to publish a standby DNSKEY in your zone.
I fail to see how publishing a DS in a CDS record for your standby key is much more safer from publishing the DNSKEY of your standby key.
I would say that if you want to publish a DS for your standby key at your parent, you can allways use the administrative bootstapping channel for that.
But then still, what's the benefit over only exposing your DS over exposing your DNSKEY, when not a single signature has been created or published with that standby key?

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, 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: Wes Hardaker <[email-masked]>
Date: Wed, 03 Jul 2013 09:01:50 -0700

Antoin Verschuren <[email-masked]> writes:

> In simple words, what do I do as a parent (or parental agent) when I
> recieve information over the DNS that conflicts with data I receive
> over the administrative channel. Which data should I follow.

Well, ordering really matters for that, right?  I mean there are two
choices:

1) I detect a change in DNS data and then receive an operational change
   via HTTP or some other mechanism.

   In this case, I think it's fairly clear that the out-of-band HTTP
   configuration should always supersede.

2) I receive the HTTP request and then notice a DNS change.

   This case also looks fairly straight forward (but keep reading), as
   clearly you act on the HTTP request and then a second request (via
   DNS) comes in second.  So you act then on it.

   The only problem with this approach is when an admin really isn't
   thinking, publishing something in DNS to make a change, realizes he
   wants to act immediately and publishes something through the HTTP
   form interface that *conflicts* with the DNS publish.  The HTTP poke
   goes through immediately, because it's client initiated, so the DNS
   pull from the parent could come *after* the http submission even
   though it was published first.  If the admin failed to revoke the DNS
   CSYNC (or whatever) request when in the process of updating over
   http, that's a mistake on their part (if it conflicts at least).

   I'd argue that we shouldn't worry about solving this case, as it's
   clearly a publication of conflict of information.  We could warn
   against it in the operational guidance section though.

> It was stated that when a parent is requesting DNSKEY instead of DS,
> and the parent calculates the DS, the disadvantage is that the child
> cannot choose the digest algorithm.

You're right the parent can offer static preferences configured
elsewhere.  But it's not done in-band.  There are rumors (which I
haven't verified) that some parents dictate what algorithms they use and
the child has no choice.  I'm sure there are others that have a set of
checkboxes, which lets the child configure the parent's engine too.

(and many more parents, of course, allow for DS uploading leaving
everything in the hands of the child).

> I fail to see how publishing a DS in a CDS record for your standby key
> is much more safer from publishing the DNSKEY of your standby key.

I agree with you, assuming you can publish your DNSKEY as a separate
record (or else people may read it, cache it, memorize it, run tests
with it, etc).  But no matter how much I agree with you it won't stop
others from wanting an oxymoron: "the private public key".
-- 
Wes Hardaker
Parsons

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 5 Jul 2013 13:14:26 -0400

> Parental Agent can calculate DS records based on that."

I applied this text with the change "used to sign" --> "expected to sign" 

> deal with a larger DNSKEY and/or DS RRset.

I understand when a Human is involved in key rollover you want it to happen as 
fast as possible to minimize the chance of her forgetting a step. 
When this is fully automated in tools why is fast needed ? 

> at all parent name servers, makes the usage at the child unnecessary

I got a comment off-line saying it is better for Parents that Mandating CDS removal as then there is no 
question at parent side as what to do. When CDS is present parent needs to perform checks it is in sync. 
For now I will leave this as an open issue, 

> field to signal a polling frequency.
RFC5011 sets polling frequency based on TTL and Signature Lifetime. 

Thanks for your comments. 

	Olafur

---

From: John Dickinson <[email-masked]>
Date: Mon, 8 Jul 2013 11:54:47 +0000

Hi,

I have read draft draft-kumari-ogud-dnsop-cds-02. (Unfortunately, I have not 
had time to read all the on list discussion, so apologies if I duplicate 
comments)

IMHO:

Section 1.2 and 2.2.1 (Highlighted roles) should be combined and used 
consistently through-out.

Section 2.1 refers to parties, section 2.2 refers to entities. One should be 
chosen and added to 1.2/2.2.1.

2.2: 
- last instance of the word organization should be plural
- s/same as operates the enterprises DNS servers/same as that which operates 
the enterprises DNS servers/
- "A domain name holder (child)" - It is not immediately obvious if this is the
child defined in the subsequent section. 

2.2.1:
- Remove the "word" DNS from the end of both DNS operator definitions.
- s/clutural/cultural/
- s/child delegation/Child/

2.3:
- s/In number/In a number/
- s/A further complication is when the DNS Operation is separate from the
   Registrant./A further complication is when the Child DNS operator is not the
    Child./
- The sentence, "There are two common cases of this, registrar handles
   the DNS operation and a third party takes care of the DNS operation." would 
   be clearer if it read something like "There are two common cases of this 
   a) the registrar handles the DNS operation or b) a third party takes care of 
   the DNS operation."
- reorder the following sentences to reflect the order a,b above.
- "the Registrant either needs to relay changes in DNS delegation" are we 
   changing the delegation (implies NS to me)?
- "we will use the word "Child Operator", is this the same as Child DNS operator
   defined in 2.2.1? Also s/word/phrase/

2.4:
- "After a DNS operator first signs its zone" whose zone, which DNS operator?

3:
- First paragraph has nothing to do with the CDS (Child DS) record definition 
   and should be (re-)moved.

3.1:
- Add a reference to the DS wire and presentation format. Also is there a need 
   to give a reference for the RR code?

3.1.1:
- Given the difficulties that can occur with going unsigned, I think this 
   section should be removed.

4.1
- much of the text in this section is not really about CDS Publication. The first 
  sentence talks about consumption as does the final paragraph. Remove all text
  except the Location, Signer and Continuity sections. Keep the text "the 
  absence of CDS record signals "No change" in the current DS set.  The use of 
  CDS is optional."  Remove the MUST from Continuity - You can not tell a child 
  DNS operator not to break their or their customers own zone - It might be a 
  bad idea, but if that is what they want to do then so be it. It might be 
  better if Continuity was at least in part the parents responsibility

4.2 and 4.3
- Move the final paragraph of 4.2 to section 4.1
- Move the third paragraph of 4.3 to section 4.1
- I dislike the wording in these 2 sections especially the 
   term, "Parental Agent" who is this in 1.2/2.2.1? 
   I suggest the following text:
--------------------------------------------------------------------------------
4.2.  CDS Consumption

4.2.1 Detecting a changed CDS
   How the Parent DNS operator (or registrar??? I will just use the term 
   Parent DNS operator from now on) detects changes to a CDS record may differ, 
   below are two examples of how this can take place.

   Polling  The Parent DNS operator operates a tool that 
            periodically checks each delegation that has a DS record to see 
            if there is a CDS record.

   Pushing  The Parent DNS operator in its user interface has a button 
            {Fetch DS} that when pushed initiates the CDS processing. If the 
            Parent zone does not contain a DS for this delegation then the 
            "push" MUST be ignored.

   In either case the Parent DNS operator may apply additional rules
   that defer the acceptance of a CDS change, these rules may include a 
   condition that the CDS must remain in place and valid for some time period 
   before it is accepted. It may be appropriate in the "Pushing" case to assume
   that the Child is ready and thus accept changes without delay.

   If the CDS RRset does not exist, the parent MUST take no action.
   Specifically it MUST NOT delete or alter the existing DS RRset.

4.2.2 Using the new CDS
   Regardless of how the Parent DNS operator detected changes to a CDS RR, the 
   Parent DNS operator MUST use a DNSSEC validator to obtain a validated CDS 
   RRset from the Child zone. It would be a good idea if the Parent DNS operator 
   checked all NS RRs listed at the delegation. However, due to the use of 
   technologies such as load balancing and anycast, this should not be taken as 
   proof that the new CDS is present on all nodes serving the Child zone.

   The Parent DNS operator MUST ensure that old versions of the CDS RRset
   do not overwrite newer versions.  This MAY be accomplished by checking that 
   the signature inception in the RRSIG for CDS is newer and/or the serial 
   number on the child's SOA is greater. This may require the Parent DNS 
   operator to maintain some state information.

   The Parent DNS operator MAY take extra security measures. For example, to 
   mitigate the possibility that a Child's key signing key has been compromised.
   The Parent DNS operator may, for example, inform ( by email or other 
   methods ) the Child DNS operator of the change.  However the precise 
   out-of-band measures that a parent zone SHOULD take are outside the 
   scope of this document.

   Once the Parent DNS operator has obtained a valid CDS it 
   MAY double check the publication rules from section 4.1. In particular the 
   Parent DNS operator MUST double check the Continuity rule and do its best not
   to invalidate the Child zone. Once checked and if the CDS and DS ``differ'' 
   it may apply the changes to the parent zone. 

--------------------------------------------------------------------------------

section 4.3 no longer exists

4.4
- Again terminology is a bit inconsistent

General Comments:
1. How will a "Child" know that the "Parent" is 'doing" CDS?
2. Section 4.4 makes this situation worse in requiring The DNS Parent to publish
   guidelines for the children as to what digest algorithms are acceptable 
   in the CDS record
3. Given the vast range of possible interactions described in 2.2.1 I am not 
   sure that this is any better than a child sending an "update".
4. Maybe I have missed this discussion, but, would it be better if 
   the "Child" published a "CDS" containing the DNSKEY and left it up to 
   the "Parent" to digest?
5. I know I am biased! There is no discussion of key timing. I think 
   that 4.1 should contain at least a reference to at least one of 
   the excellent (expired but could be resurrected) drafts on the subject.

regards
John

---
[email-masked]

http://sinodun.com

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

+44 (0)1491 834957

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 8 Jul 2013 14:03:38 -0400

John,

Thanks for a excellent and timely review we just about pushing out a new version when it arrived. 

We have accepted most of your edits and suggestions except when the text was already removed/reworded. 

Instead I want to focus on your Q1: "How will a ``Child'' know if the ``Parent'' is doing CDS?" 
IMHO, we need to figure out how/if to place a flag in parent saying what kinds of "sync" it is willing to do from signed children. 

	Olafur 

>   and should be (re-)moved.
This paragraph was moved to background section. 

>   I suggest the following text:

see above. 
>   sure that this is any better than a child sending an "update".

Open issue "where to send update to?"

>   the "Child" published a "CDS" containing the DNSKEY and left it up to 

Religion issue, CDS is 'easier' to compare than DNSKEY 
>   the excellent (expired but could be resurrected) drafts on the subject.
good suggestion, added reference 

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 8 Jul 2013 20:28:41 +0200

I have also had a look at this document which I in general do believe is sound, although there are a few events I would like to have described in the document. Reason for this is that I see it being really important that it is implemented the same way in all usage scenarios.

One such situation is what is to happen when NS records changes in the parent zone.

An immediate reaction is that change of NS records should trigger fetch of CDS record from the child zone so that the new DS can be included in the new version of the zone that have the new NS records. Careful thinking should say whether that is a correct thinking of me.

Another situation is what to do (by the parent) when inconsistent CDS records are found from the authoritative servers for the zone (with and without identical serial numbers in the SOA).

And a third if the auth servers queried at should be the ones that there are NS records for in the parent zone or the NS records that exists in the child zone.

This to resolve inconsistencies between information in parent and child zones and between auth servers.

Lastly, I think it should be very clear not only what the priority is between different versions of CDS records, but also between CDS records and epp commands. If different registries implement different policies here, the world might risk being much messier than what we want.

Hope this helps.

   Patrik

---

From: "Dickson, Brian" <[email-masked]>
Date: Mon, 8 Jul 2013 18:49:53 +0000

On 7/8/13 2:28 PM, "Patrik Fältström" <[email-masked]> wrote:

>I have also had a look at this document which I in general do believe is
>sound, although there are a few events I would like to have described in
>the document. Reason for this is that I see it being really important
>that it is implemented the same way in all usage scenarios.
>

I think, perhaps, that a corresponding mechanism for NS change (or change
validation), will be what we eventually conclude is also a good idea (or
even necessary to provide some means of protection/validation to an
otherwise unprotected-but-critical element).

For the same kinds of reasons as parent/child DS vs DNSKEY "mismatch"
(pre-publication of DS without publication of DNSKEY), there are reasons
that parent and child NS sets are not always the same.

So, using the child NS set to directly validate the parent NS set is a
non-starter.

However, maybe something like a "PNS" (parent NS) in the child, where the
child is authoritative for the data, could signal {change | validation}
(depending on the RRR requirements), would do the trick?

Upon receiving a change request for the NS set, the zone publisher could
check the child for matching PNS records.

Facilitates automation, just as CDS would.

Thoughts?

Brian

>
>An immediate reaction is that change of NS records should trigger fetch
>of CDS record from the child zone so that the new DS can be included in
>the new version of the zone that have the new NS records. Careful
>thinking should say whether that is a correct thinking of me.
>
>Another situation is what to do (by the parent) when inconsistent CDS
>records are found from the authoritative servers for the zone (with and
>without identical serial numbers in the SOA).
>
>And a third if the auth servers queried at should be the ones that there
>are NS records for in the parent zone or the NS records that exists in
>the child zone.
>
>Lastly, I think it should be very clear not only what the priority is
>between different versions of CDS records, but also between CDS records
>and epp commands. If different registries implement different policies
>here, the world might risk being much messier than what we want.
>
>Hope this helps.
>
>   Patrik
>

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 8 Jul 2013 21:32:19 +0200

> (depending on the RRR requirements), would do the trick?

Might solve some events, but I do not think it solves the most important situation, that DNS is moved from one DNS provider to another. The old DNS provider can not be asked to enter NS records for the gaining provider... And using NS (in reality, as you look for auth servers) to fetch NS data seems to me be a bit...fishy... ;-) The attack vector against such a situation is very complicated.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 8 Jul 2013 21:39:58 -0400

> Thoughts?

My immediate thought is, "What problem is this trying to solve?"

In the DNSSSEC case, the problem is that you're trying not to break
the chain of trust, and you need a mechanism that is cryptographically
securable to make the communication.  This is made harder in some
sense by the fact that the DS and DNSKEY RRsets are authoritative on
different sides of the zone cut.

In the NS case, because the child side RRset is the really
authoritative one, that's the one that generally gets cached.  Since
both sides of the cut have the same RRTYPE, and since only one of the
RRsets can be cached, you end up with only one such set and it's the
one that gets used.

It's it possible to bollocks this so that resolution fails?  Yes.  But
that's not a result of disagreement between two different RRsets, so
in this case having the additional communication path (especially
inside the DNS) is less necessary.

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 9 Jul 2013 09:46:05 +0200

Op 08-07-13 20:28, Patrik Fältström schreef:

> An immediate reaction is that change of NS records should trigger
> fetch of CDS record from the child zone so that the new DS can be
> included in the new version of the zone that have the new NS
> records. Careful thinking should say whether that is a correct
> thinking of me.

Why would DS records change when NS records change?
I guess you're thinking only one scenario here, and that is when NS
records change, the DNS operator of the master changes and the zone
will get different key material. But this is not the general case,
only the most difficult one to solve. Only changing one slave NS by
another does not change the operator maintaining the key material.

Changing the operator maintaining the key material does happen, and
when it does, changing the DS after changing the NS will not help you
autoprovision. The zone will get bogus if you change the DS after
changing the NS, and so no CDS change can be validated at all.
Changing the key material operator needs pre-publishing of the new key
material in the zone of the losing operator for the NS change to be
validated. The new NS RRset in the child is signed with the new key
material only.
I know you all wish the world was simpler, but it isn't, We've tried.

> And a third if the auth servers queried at should be the ones that
> there are NS records for in the parent zone or the NS records that
> exists in the child zone.

I agree with Andrew here that the NS RRset in the child zone is
authoritative, but it can only be used if validated.

> Lastly, I think it should be very clear not only what the priority
> is between different versions of CDS records, but also between CDS
> records and epp commands. If different registries implement
> different policies here, the world might risk being much messier
> than what we want.

Exactly my statement.

- -- 
Antoin Verschuren

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

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 9 Jul 2013 09:51:48 +0200

Op 08-07-13 20:49, Dickson, Brian schreef:

> Upon receiving a change request for the NS set, the zone publisher
> could check the child for matching PNS records.
> 

That's why I said I liked draft-hardaker-dnsop-csync-00.txt better, as
it tries to solve the more general case of sending technical
delegation data from child to parent, whether it is NS, DS, DNSKEY, or
any other records we might need in the future to maintain a delegation.

- -- 
Antoin Verschuren

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 9 Jul 2013 10:05:17 +0200

On 9 jul 2013, at 09:46, Antoin Verschuren <[email-masked]> wrote:

> Signed PGP part

I am only saying change of the NS record should _trigger_ a fetch of the CDS. If the CDS has not changed, then the DNSSEC data in the parent should not change.

> changing the NS, and so no CDS change can be validated at all.

The registry get an EPP update via a secure channel to change the NS. They can at that time (before the new zone is published) issue queries for CDS at the suggested new target of the NS, and if the CDS exists there they can fetch the CDS, see if key material changed, and incorporate the data in the zone that is to be published.

> I know you all wish the world was simpler, but it isn't, We've tried.

For newcomers to this discussion, Antoin and myself is in the middle of this discussion about how to do a change of DNS operator (and because of that change of maintainer of key material) in reality. We have, as you can see, different opinion on the topic :-)

> authoritative, but it can only be used if validated.

But it can be validated thanks to the trust in the epp channel.

   Patrik

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 9 Jul 2013 11:56:46 +0200

Op 09-07-13 10:05, Patrik Fältström schreef:
> 
> The registry get an EPP update via a secure channel to change the
> NS. They can at that time (before the new zone is published) issue
> queries for CDS at the suggested new target of the NS, and if the
> CDS exists there they can fetch the CDS, see if key material
> changed, and incorporate the data in the zone that is to be
> published.

That CDS record will not validate at that point in time, so it will
always be ignored.
The pre-requisite for CDS is that the record can be validated, and the
new zone is not yet in the chain of trust if the DNSKEY RRset that is
present in the validating resolver does not contain the key by which
the CDS record in the new zone is signed.

You could do a theoretical validation of that record with the assumed
future state of the zone and delegation at the parent, but all
validating resolvers in the real world will have a DNSKEY RRset cached
from the past, and are not aware of any future change until after it
has happened. So during the DNSKEY TTL all records that should
validate against the DNSKEY RRset will have a chance of being bogus,
depending on from which zone the signatures come and which DNSKEY
RRset is cached..
Unless you have pre-published a DNSKEY RRset that contains the ZSK's
of both zones, so both signatures validate.

But then there is no need to query the CDS record, because you cannot
do a simultaneous second key rollover during a key maintainer change.
You'll have to wait at least one child NS TTL after the NS change at
the parent until it's safe to remove the old key and do another key
rollover, so querying CDS immediately after changing the NS at the
parent will always result in zero changes if you want your zone to work.

- -- 
Antoin Verschuren

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 9 Jul 2013 09:47:13 -0400

On Jul 9, 2013, at 5:56 AM, Antoin Verschuren <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Antion,  is right  CDS or CSYNC can only help with operator change
when the OLD operator is highly cooperative. 
Old Operator has to be  willing and able to publish change information about the new operator 
in its copy of the zone and it has to publish it long enough for the 
parent to pick it up.

	Olafur

---

From: "Dickson, Brian" <[email-masked]>
Date: Tue, 9 Jul 2013 23:06:11 +0000

>My immediate thought is, "What problem is this trying to solve?"

Automating NS changes on the parent side, via child-signed-and-signalled
in-zone data. If the CDS keys are needed for a change of DNS provider,
it implies a new NS set on the parent (as well as the apex of the child).

E.g. if someone needs to move a bunch of domains from one set of name
servers
to a different set, tools are likely better than doing it manually. CDS
addresses the DS/DNSKEY part, but leaves the NS part unchanged.

It's a problem which I presume exists or might exist, which goes along
with the CDS problem: how do you automate "X", where "X" is currently
done via web form? ("Automate" might merely be "integrate into a
provisioning
system").

I don't know if the problem actually exists, so until someone says,
"Yeah, it is a problem", it is probably premature.

It would really only make sense (or add value) if the domains were
already DNSSEC delegations, and already doing CDS.

If the key roll is being prompted by NS changes, then tying (loosely or
tightly) the NS move with the CDS change, then the process reduces the
probability of resolution breaking for any of the bunch.

It would make sense basically only if the "PNS" RRset was signed, and
would provide cryptographic protection on it, allowing for an in-band
method of changing the NS on the parent side.

It's not necessary, merely a convenience, or a way of facilitating better
provisioning tools.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Wed, 10 Jul 2013 09:19:17 -0400

> I know you all wish the world was simpler, but it isn't, We've tried.

I'd voiced support for CDS before and have even gone as far as visiting with Olafur and Warren to work on the mechanism.

But since the last conversation, I'm not as optimistic.  In part because of what Antoin wrote above.

I wish that we could have something done only in-band but I also think it will be impossible to achieve this.

The CDS proposal is fine for answering the question of how data is marshalled, but it doesn't answer other factors.  I haven't been able to draw a circle around the other factors - is what we are trying to achieve a "transaction" or a version of a "remote procedure call" or something else.

That the child has no information about the parent - in the sense that some parents have cutpoints deeper than 1 and that the child zone has no information about the parent name servers, knowing where how to locate the service is difficult.  (I'm leaving out the possibility of using a recursive server to discover the parent because that's a function that you really don't want in a key management system or an authoritative server.

There is also no "semaphore" system in place that will inform the parent and child what state of the DS transfer is in.  The draft assumes a poll cycle on the parent and detection by the client - but what if there's a race condition?  Or one side gets stuck in a state (of the protocol state machine) and leaves the other side spinning?

These are concerns that are not well defined and I've off and on tried to find a more rigorous framework from which to hang them.  But Antoin sums up the "operator" view that - the world is more complicated than a simple solution away from completeness.

I said "I'm not as optimistic."  This doesn't mean I'm pessimistic nor withdrawing support for working on this in the working group.  There's a need to make DS management easier but a simple solution is no longer what I envision.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 Jul 2013 22:46:51 -0400 (EDT)

On Wed, 10 Jul 2013, Edward Lewis wrote:

> These are concerns that are not well defined and I've off and on tried to find a more rigorous framework from which to hang them.  But Antoin sums up the "operator"
> view that - the world is more complicated than a simple solution away from completeness.
> 
> I said "I'm not as optimistic."  This doesn't mean I'm pessimistic nor withdrawing support for working on this in the working group.  There's a need to make DS
> management easier but a simple solution is no longer what I envision.

Then maybe we should split it in draft-kumari-ogud-dnsop-cds-no-rrr and draft-kumari-ogud-dnsop-cds-secure-kitchensink-2015

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 Jul 2013 22:49:37 -0400 (EDT)

> "Yeah, it is a problem", it is probably premature.

You mean all the lame delegations in the world doesn't show an actual
problem? I'm not sure I'm understanding you.

Paul

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 11 Jul 2013 12:54:57 +0200

Op 10-07-13 15:19, Edward Lewis schreef:

> These are concerns that are not well defined and I've off and on
> tried to find a more rigorous framework from which to hang them.
> But Antoin sums up the "operator" view that - the world is more
> complicated than a simple solution away from completeness.

I've given Ed's words a really good thought, and slept a night over it.
I think the reason why some of us don't feel comfortable  with many of
the assumptions in our requirements is because we try to avoid a
framework we as technicians are not comfortable with, and that is trust.
Trust is more a layer's thing. As sysadmins we expect trust is
evident, and we all try to do "the good thing" so why would anyone
doubt us at some point. We don't realize trust is something that needs
to be gained by convincing somebody else to express it, it cannot be
self-proclaimed.

In the CDS discussion, we have already identified some situations
where even for us it is evident CDS does not work, and I'm trying to
translate that to a more generic definition in stead of "a gut feeling".
We've said that CDS, or CSYNC to be more generic, is not useful for
bootstrapping a delegation, i.e. registering a delegation for the
first time. It also does not work when the delegation path is broken,
f.e. when a key is compromised. And the most recent case is when one
of the roles in the process of maintaining a delegation changes. These
are all situations where initial trust needs to be build-up,
re-established, or re-initialized. CSYNC and CDS try to solve a
problem for a static operational state where technical information
needs to travel from child to parent to maintain that relationship.
And in that static state, it can work fine, and as Ed, I'm all for it.

So defining where CSYNC cannot work because of a lack of trust is the
first thing we need to do, and I'll give it a try:

1. Bootstrapping
The initial appointment of trusted roles in a delegation must be set
up over an out-of-bound channel, and therefor CSYNC cannot be used for
bootstrapping the initial delegation. So registration of the initial
technical parameters of a delegation must take place over an
out-of-bound secure channel. In simple words: Registering a domain for
the first time is done over EPP, not over DNS.
2. Re-bootstrapping
When one of the roles in the out-of-bound channel is changed, a
renewed trust must be expressed. The roles we know of that are present
in the out-of-bound channel are:
Registry-Registrar-Reseller-Registrant-DNS operator-key maintainer.
When one of these roles is changed to another entity, the delegation
needs to be re-bootstrapped over the out-of-bound channel for everyone
in that out-of-bound channel to be aware of it's new trust
relationship. In simple words: Changing a Registrar, Registrant,
Reseller, DNS-operator, or DNSSEC key maintainer for a zone cannot be
communicated over DNS, but it must use EPP.
3. Re-initialising a bootstrap
When a (secure) delegation fails, because of a lame delegation, key
compromise, or misconfiguration of any other technical parameter
causing the delegation to break or trust to be absent, restoration of
that trust needs to be established over the out-of-band channel. In
simple words: Emergency keyrollovers in case of key compromise, or
restoration of lame delegations cannot use DNS but must be done over EPP.

So CDS and CSYNC only have a use case for the maintenance of a static
delegation, and I really think this is not a waisted effort. I
personally would like to solve the more generic question of a
technical parameter to travel from child to parent as in the CSYNC
draft, as opposed to the only one use case one scenario of getting a
DS renewed at the parent as focused on in the CDS draft.

> That the child has no information about the parent

I don't have an answer for Ed's question about how to identify the
entry point at the parent for a child.
I really liked the concept of a "parental agent" in the CDS draft, but
that is a role definition in the administrative out-of-bound channel.
I really think we need to separate roles in the administrative and
technical model for a delegation for our concepts to work.
So "parental agent" is an excellent term to describe who is above you
in the administrative out-of-bound channel, but it does not have any
synonym or responsibility in the technical DNS model.
I know we invented this because it's hard to change the ICANN lawyers
minds that registrars are responsible for administration and
bootstrapping technical parameters for a delegation only. Perhaps when
we add the list above to the responsibility of registrars, and clearly
define that CSYNC or CDS is for technical maintenance of a static
delegation, we can convince them that it is ok for a (DNS) child to
talk directly to the (DNS) parent, and then identification of a parent
can fairly easy be done in the DNS.

Thoughts, additions?

- -- 
Antoin Verschuren

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 11 Jul 2013 07:28:59 -0700

> to be gained by convincing somebody else to express it, it cannot be

Quite right. But there is a second reason: the proposals are trying to use the DNS protocol to transmit the data and, seeing the limitations of doing so, adjust their requirements. A different way to design the protocol would be to list the real requirements and stick to them. This would very likely involve using a different communications protocol, such as RESTful-HTTP-over-TLS. 

--Paul Hoffman

---

From: John Dickinson <[email-masked]>
Date: Thu, 11 Jul 2013 15:34:53 +0000

> IMHO, we need to figure out how/if to place a flag in parent saying what kinds of "sync" it is willing to do from signed children. 

I don't see the point of a flag. Since the auth servers for the child and parent never talk to each other the child would have to set up some tool to see the flag. It seems likely to me that the parent would have to give info about  such a flag on a web page somewhere so the web page might as well be the flag.

regards
John

---
[email-masked]

http://sinodun.com

+44 (0)1491 834957

---

From: Warren Kumari <[email-masked]>
Date: Fri, 12 Jul 2013 08:19:30 -0400

> Might solve some events, but I do not think it solves the most important situation, that DNS is moved from one DNS provider to another. The old DNS provider can not be asked to enter NS records for…

And is *precisely* why this document / technique is not trying to "solve" it.

CDS is specifically only for rolling your DNSKEY. It is specifically NOT for:
establishing trust.
recovering from a key compromise.
changing operators.
changing your NS.
a duck.

It is designed to be easy to clean, simple and easy to implement. It is designed to solve the "common case" -- there are a whole slew of cases that it simply rules out of scope.

This is designed to be the answer to "I feel like I should roll my keys because XXX, but I'm simply too lazy / likely to screw it up with the current interface" -- where XXX is something related to age, some policy, etc, NOT because I wandered into the directory where I store keys and found a file called exploit.php…

If I need to move DNS hosting folk, change my NS records, transfer my domain to another registrar,  revoke all keys, etc I'll go "old skool" and do the out of band / web dance.

We want to make this annoying (probably repetitive) bit easier, ocean boiling is left for later….

[ Please note: I'm currently sitting in a hotel in South Africa, with less than stellar Internet access, and a funny timezone. Replies may be terse and delayed. ]

W

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 12 Jul 2013 08:27:20 -0400

> And is *precisely* why this document / technique is not trying to "solve" it.

This is why this is a good idea to me.