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

From: Warren Kumari <[email-masked]>
Date: Mon, 17 Jun 2013 13:32:30 -0400

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.

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)

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jun 2013 14:28:12 -0400 (EDT)

> The authors believe this version is ready for WG adoption and request the DNSOP chairs to kick off an adoption call.

I am in favour of adopting this draft as a WG item.

Some comments:

Section 3.1.1:

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)

I strongly prefer the CDS and DS digest algorithms to be identical, so I
am not in favour of some special kind of CDS digest overloading for the
meaning of transition from secure to insecure.

Section 4.2

I think it _is_ able to use a standard validator. It just needs a
non-standard trust anchor loading for confirmation the path of trust
will not break.

Typos:

thus it is not be able -> thus it is not able

If one exits it applies  -> If one exists it applies

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 21 Jun 2013 14:58:02 -0700

> I am in favour of adopting this draft as a WG item.

Ditto.

> (infrequent) change should have an additional authentication, eg via EPP

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.
-- 
Wes Hardaker
Parsons

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 25 Jun 2013 12:05:22 +0200

Hi,

>> I am in favour of adopting this draft as a WG item.

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.

> 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):

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

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

* Section 3.1.1. As said above, I don't like the idea of using the CDS
record to go unsigned.

* Nit: Section 4.1. I think the last paragraph fits better in section
4.2. CDS Consumption.

* Section 4.2. About the polling strategy. I am wondering how well this
scales with respect to the number of delegations.

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

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.

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

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.

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

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

Best regards,
  Matthijs

*

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Jun 2013 14:14:11 -0400

> topic of automating the synchronization between DNSKEY at the child and

Thank you all.

We are still awaiting the official kickoff of the Call for Adoption. I'm *assuming* the chairs will be willing to accept these as demonstration of support. 
If you respond to the official CfA as well, please also indicate if you are willing to review (I believe DNSOP wants 5 folk who support *and are willing to review*).

> is proposed, must be added, deleted, is valid for only this period etc.

Thanks.

> Comments on the draft (apologies for its length):

*No* need to apologize for length -- we really appreciate detailed feedback. 
We will be having a meeting later this afternoon and will discuss your comments -- at a quick glance they all seem sane and worthwhile to me…

Thanks again,
W

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

-- 
No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft.
                --Anon.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Jun 2013 09:02:35 -0400

In the land of looking for support to take this on, the WG should.  Adoption by the WG or not, I'm taking this seriously and will help engineer this through to solution.

>>  trust anchors for a domain.

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

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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 27 Jun 2013 10:55:17 -0400

> In the land of looking for support to take this on, the WG should.  Adoption by the WG or not, I'm taking this seriously and will help engineer this through to solution.

Thank you. 

Now we just need the chairs to wave the terrible thurible, thereby incensing the censer[0] and officially kick off a CfA.

W

[0]: Horribly contrived, I know, but couldn't resist.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 28 Jun 2013 14:18:01 -0400

> topic of automating the synchronization between DNSKEY at the child and
Thanks

> Comments on the draft (apologies for its length):

Thanks for the comments. 

> interactions with the parent".

Applied 

> DNSKEY RRset". That is not true. Without the SEP bit, the key may also

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

> * Section 3.1.1. As said above, I don't like the idea of using the CDS

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

Reworked both sections to address 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. 

> to mitigate against a compromise. The compromise allows the attacker to

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? 

> * Section 4.3. I wonder if the SHOULD in the first sentence should be a
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. 

> CDS records for the digest algorithm(s) it require(s)" (CDS instead of

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. 

> Double-DS based rollovers are not possible in combination with CDS.

exactly 

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

> TTL to suggest a polling frequency for the parental agent. Just some
I had not thought about guidance on the CDS TTL, nor on the signature lifetime on the record. 
You have any ideas? 

>  Matthijs
Thanks for great review. 

	Olafur