Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds

From: Tim Wicinski <[email-masked]>
Date: Sun, 3 Apr 2016 18:29:00 -0300

This starts a Working Group Last Call  for draft-ietf-dnsop-maintain-ds

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

Feel free to show up at DNSOP's Wednesday session and voice your 
approval or disapproval.

This starts a two week Working Group Last Call process, and ends on
	17 April 2016

thanks
tim

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 4 Apr 2016 00:25:51 -0300

Dear colleagues,
a new version of the document has been posted that fixes few minor
grammatical and spelling errors.

this is version 02
URL:
https://www.ietf.org/internet-drafts/draft-ietf-dnsop-maintain-ds-02.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-02

Olafur

On Sun, Apr 3, 2016 at 6:29 PM, Tim Wicinski <[email-masked]> wrote:

> Feel free to show up at DNSOP's Wednesday session and voice your approval
> or disapproval.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Bob Harold <[email-masked]>
Date: Tue, 5 Apr 2016 09:42:37 -0400

On Sun, Apr 3, 2016 at 11:25 PM, Ólafur Guðmundsson <[email-masked]>
wrote:

> Htmlized:
> https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-02
> Diff:
Looks good to me.  One more typo:

 5.  Security considerations
-- end of last sentence:
"after a certain about of wait time - thus allowing a child
   administrator to cancel the request."

"about" should be "amount"

---

From: Richard Lamb <[email-masked]>
Date: Wed, 6 Apr 2016 16:33:32 +0000

Olafur-

Read it.  Liked it. No changes needed. Now implementing it.

Thank you for doing this and finishing/clarifying the CDS work.  Will send you a note when I have things running.

-Rick

From: DNSOP [mailto:[email-masked]] On Behalf Of Ólafur Guðmundsson
Sent: Sunday, April 3, 2016 8:26 PM
To: Tim Wicinski <[email-masked]>
Cc: dnsop <[email-masked]>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds

Dear colleagues,
a new version of the document has been posted that fixes few minor grammatical and spelling errors.

this is version 02
URL:            https://www.ietf.org/internet-drafts/draft-ietf-dnsop-maintain-ds-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-02

Olafur

On Sun, Apr 3, 2016 at 6:29 PM, Tim Wicinski <[email-masked]<mailto:[email-masked]>> wrote:
This starts a Working Group Last Call  for draft-ietf-dnsop-maintain-ds

Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for publication, please speak out with your reasons.

Feel free to show up at DNSOP's Wednesday session and voice your approval or disapproval.

thanks
tim

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

---

From: "Rose, Scott (Fed)" <[email-masked]>
Date: Wed, 6 Apr 2016 17:07:09 +0000

I read the draft and support it.  Suggest one wording change though:  In the draft the term "trust anchor" is used when is should really be "secure entry point".  At least to keep it in line with the dns-terminology draft and the fact that the KSK for the zone may not be a trust anchor.

Scott

________________________________
From: DNSOP <[email-masked]> on behalf of Bob Harold <[email-masked]>
Sent: Tuesday, April 5, 2016 9:42 AM
To: Ólafur Guðmundsson
Cc: Tim Wicinski; dnsop
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds

On Sun, Apr 3, 2016 at 11:25 PM, Ólafur Guðmundsson <[email-masked]<mailto:[email-masked]>> wrote:

Dear colleagues,

this is version 02

Olafur

thanks
tim

---

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

Thanks Bob
fixed in my repo

Olafur

> On Apr 5, 2016, at 9:42 AM, Bob Harold <[email-masked]> wrote:
> 
> 
> On Sun, Apr 3, 2016 at 11:25 PM, Ólafur Guðmundsson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Dear colleagues, 
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-dnsop-maintain-ds-02.txt <https://www.ietf.org/internet-drafts/draft-ietf-dnsop-maintain-ds-02.txt>
> Status:         https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/>
> Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-02 <https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-02>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-02 <https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-02>
> 
> Olafur 
> 
> On Sun, Apr 3, 2016 at 6:29 PM, Tim Wicinski <[email-masked] <mailto:[email-masked]>> wrote:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Richard Lamb <[email-masked]>
Date: Mon, 11 Apr 2016 16:36:49 +0000

Just to complete the thought. As promised here’s the link to my demo implementation.  https://www.co.tt/cdstest.cgi   -Rick

From: Richard Lamb
Sent: Wednesday, April 6, 2016 9:34 AM
To: 'Ólafur Guðmundsson' <[email-masked]>; Tim Wicinski <[email-masked]>
Cc: dnsop <[email-masked]>
Subject: RE: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds

Olafur-

-Rick

From: DNSOP [mailto:[email-masked]] On Behalf Of Ólafur Guðmundsson
Sent: Sunday, April 3, 2016 8:26 PM
To: Tim Wicinski <[email-masked]<mailto:[email-masked]>>
Cc: dnsop <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds

Dear colleagues,

this is version 02

Olafur

thanks
tim

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 26 Apr 2016 11:13:54 +0200

All,

I have read it and I like it. Still there are I think some things that
need to be addressed:

- On enabling DNSSEC via CDS/CDNSKEY: most of the policies assume some
sort of communication channel between the child zone operator and parent
zone operator, while in fact RFC 7344 registers new resource records
because we assume there is no such channel. CDS/CDNSKEY records are put
in the child zone to signal the desired DS RRset in the parent. The
child can only hope that the parent will pick it up and the only way to
get confirmation is to query the parent zone. So how would the parent
"send a notification requesting a confirmation" (section 3.2) or
"instruct the requestor to insert some record into the child domain"
(section 3.4)?

It could use the same CDS approach and put it in some new resource
records in the parent zone (just stick it in the DNS ;)).

Anyway, if we assume there is no other communication channel, the
document should provide more details on where to put this notification
or challenge such that the child can pick it up. If we say there is a
different communication channel, there needs to be more details about
how that channel looks. Or we should just keep saying it is a hard
problem and leave it out of scope (and solve it in yet another document).

- On using 0 as the DNSSEC Delete Algorithm in CDS and CDNSKEY records,
I think that is fine and is a cleaner approach then using a non-zero
algorithm number. The document could perhaps make it explicit it is
meant only to be used in CDS and CDNSKEY records, not DS/DNSKEY.

- The document suggests that when disabling DNSSEC, only the fixed
fields should appear in the records. Do you mean fixed length fields?

- Leaving out the Digest/Public Key field changes the definition of the
CDS and CDNSKEY records: No longer are their formats identical to the
DS/DNSKEY records. So at minimal this updates RFC 7344. Existing
versions of DNS server that support RFC 7344 will likely not be able to
load a CDS record as described in section 4 and consider it malformed.

Finally, two nits:

- Nit: The abstract gives the reader the feeling that initial trust is a
very hard problem, but then section 1.2 says it can be easily solved
with some simplifying assumptions :) Perhaps you meant to say that it is
hard to solve technically unless some reasonable policies can be assumed.

- Nit: The first use mentioned in section 2 is just KSK Rollover. What
does explaining the different operations add to the document?

Best regards,
  Matthijs

On 04/04/2016 05:25 AM, Ólafur Guðmundsson wrote:
>     Please review the draft and offer relevant comments. Also, if
>     someone feels the document is *not* ready for publication, please
>     speak out with your reasons.
>

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2016 16:13:00 -0000

>"instruct the requestor to insert some record into the child domain"

That part definitely needs to be finished.  There are a lot of us
small DNS providers and while I don't care what the mechanism is,
there needs to be some way to do automated signalling back and forth
that doesn't depend on the parent already knowing and trusting the
entity that runs the child zone.

>records in the parent zone (just stick it in the DNS ;)).

Sure, give or take ensuring it doesn't run fatally afoul of ICANN
rules about what can go in TLD zones.  (The rules can likely be
changed, but if that's what we need, there has to be a plan.)

>hard to solve technically unless some reasonable policies can be assumed.

I think the assumptions were that there's a handful of large
trustworthy DNS providers, which is true, but not an assumption we
small trustworthy DNS providers like.

R's,
John