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

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 7 Jun 2016 11:46:31 -0400

On Tue, Apr 26, 2016 at 5:13 AM, Matthijs Mekking <[email-masked]>
wrote:

> All,
>
> Matthijs thanks for the review
sorry for the delay in response.

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

Ok the current text is sub-optimal  added:
"for example by sending email to the registrant requesting a confirmation."

>
> 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 ;)).
>
That is even bigger change :-) sorry no go

>
> 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).
>
In general we envision three confirmation approaches
  - A proof of change control of zone by requesting record insertion
(covered)
  - A delay in acceptance, i.e. a stability check (covered)
  - A email to registrant asking for confirmation. (just added)
While there might be more this is all we envision.

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

done

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

changed "fixed fields" to "exactly the 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.
>

Good point, making this clearer in text

>
>
> 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?
>
> Basically setting the stage and expectations

> Best regards,
>   Matthijs
> thanks again
Olafur

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 13 Jun 2016 14:03:25 +0200

Olafur,

On 06/07/2016 05:46 PM, Ólafur Guðmundsson wrote:
> 
> 
> On Tue, Apr 26, 2016 at 5:13 AM, Matthijs Mekking
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     All,
> 

...

> That is even bigger change :-) sorry no go 

I thought so already :)

Still it is unfortunate that we are not able to close the final gap of
fully automating DNSSEC, but at least we are making the gap smaller and
smaller.

> While there might be more this is all we envision. 

I still think Section 3 is on the weak side and has almost the same
value as the oneliner: The authentication mechanism for verifying the
child really wants to enable DNSSEC is out of scope for this document.

> Good point, making this clearer in text 

An alternative solution can be: In case the DNSSEC algorithm is 0, the
Digest/Public Key MUST be ignored.

> Basically setting the stage and expectations 

I think it is confusing, since the document does later not mention the
ADD and REPLACE operation. Personally I would just say: "KSK Rollover"

Best regards,
  Matthijs

---

From: "John Levine" <[email-masked]>
Date: 13 Jun 2016 16:52:08 -0000

>fully automating DNSSEC, but at least we are making the gap smaller and

I'd also like more concrete advice on initial DS, but I can see why we
need to wait and see what DNS providers are willing to do.

With that in mind, this draft is as good as it's going to get, so ship it.

R's,
John