Subject: [DNSOP] draft-ietf-dnsop-maintain-ds adding vs. deleting DS, and document track

From: Shane Kerr <[email-masked]>
Date: Wed, 6 Apr 2016 16:50:14 -0300

Hello,

RFC 7344 left out the problems of deletion and addition because they
were scary.

I think that the draft-ietf-dnsop-maintain-ds document is quite clear
about deleting DS records, and I think it makes sense.

However, in the case of adding DS records, to me the document is less of
a specification than a discussion about possible approaches to the
difficult issue of when to accept the CDS RRset. This discussion is not
necessarily a problem, because that's all we have today.

The reasons that I questioned whether this draft should result in a
standards-track document is because of the ambiguous and vague way that
DNSSEC is enabled with CDS/CDNSKEY.

I do think that RFC 7344 should be standards track.

To be clear, I'm not strongly opposed to standards track, but I am not
sure what it means to have a standards track document that doesn't
actually tell me how to inter-operate or even really how to do anything
concrete. (This might just be my IETF ignorance, I admit!)

Cheers,

--
Shane

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2016 22:14:58 -0000

>concrete. (This might just be my IETF ignorance, I admit!)

I agree that it needs to be tightened up a lot to interoperate.  When
I said we should adopt it, that doesn't mean we should approve it
exactly in its current form.

R's,
John

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 6 Apr 2016 22:55:10 -0400

> On Apr 6, 2016, at 3:50 PM, Shane Kerr <[email-masked]> wrote:
> 
> Hello,
> 

Shane thank you for starting this discussion, 
We could have written 
“After observing CDS records for 15 days or 2 resigning cycles which ever is longer, accept them and upload DS” 
Is that  better ? 
It sets expectations 
But there is the case Parent happens to know the operator of the domain and via out of band knowledge can be
sure the domain is operated a that party. In this case the upload should not suffer any delay. 

So yes I agree having well defined policies is a good idea, but we need help and guidance in 
making the text better and figure out 2 or 3 reasonable policies, to recommend to people 

> DNSSEC is enabled with CDS/CDNSKEY.

I get your point, and kind of agee with it (have not asked my co-editor what he thinks)

> I do think that RFC 7344 should be standards track.

Great, 

> concrete. (This might just be my IETF ignorance, I admit!)

I think having this on standards track is better than not. 
If there is bad advise in the document we can always replace it with better RFC. 

Olafur

---

From: "John Levine" <[email-masked]>
Date: 7 Apr 2016 21:33:40 -0000

>“After observing CDS records for 15 days or 2 resigning cycles which ever is longer, accept them and upload DS” 

I think my users (the ones who know about DNSSEC) would not be happy
to hear that their entirely valid signed zone won't be verifiable for
two weeks, just because I am not as cool as some others are.

>sure the domain is operated a that party. In this case the upload should not suffer any delay. 

It needs to be stronger than that, define a small set of automatable
ways (ideally just one) that the uncool child can verify its bona
fides to the parent.  It's fine for domains to opt out of them for
security reasons, but in most cases where the registration is only
secured by a password, it'll be fine.

R's,
John

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 7 Apr 2016 22:25:40 -0400

> On Apr 7, 2016, at 5:33 PM, John Levine <[email-masked]> wrote:
> 
>> We could have written 

John, does the challenge mode addresses your concerns?
i.e. parent gives the “uncool” operator something to insert into the zone to prove they can change the zone. 

Olafur

---

From: "John R Levine" <[email-masked]>
Date: 8 Apr 2016 01:31:51 -0300

> i.e. parent gives the “uncool” operator something to insert into the zone to prove they can change the zone.

Sure.  Anything that's straightforward to automate is fine.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Apr 2016 11:23:20 -0400 (EDT)

> two weeks, just because I am not as cool as some others are.

Clearly this is all local policy of the parent zone, and as such should
not be specified in this document.

> secured by a password, it'll be fine.

This goes into RRR territory, which is a local policy that does not
apply to all parents.

Stating it is the parent's decision is what this document does. It
should not attempt to do more. It suggests example methods without
specific details about timing.

If we could come up with "ideally one" method that would be acceptable
to everyone, we wouldn't have ended up in the posistion that we needed
to write this draft to begin with, and this would have been resolved
years ago in the "triggers vs timers" discussion.

Paul