Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-multi-provider-dnssec

From: Benno Overeinder <[email-masked]>
Date: Sat, 16 Nov 2019 10:42:52 +0800

Hi all,

The WGLC date has passed and we think the draft is in good shape. Still
the chairs would like to see some comments and feedback.  Positive
feedback that the document is ready to go is also fine.

Thanks,

-- Benno

On 31/10/2019 16:47, Tim Wicinski wrote:
> 
> This starts a Working Group Last Call for
> draft-ietf-dnsop-multi-provider-dnssec
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/
> 
> The Current Intended Status of this document is: Informational
> 
> FYI, I will not shepherd this document, as it was written with several
> of my coworkers.
> Benno Overeinder will be Document Shepherd. 
> 
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out. 
> If someone feels the document is *not* ready for publication, please
> speak out with your reasons.
> 
> If there are normative issues, agenda time at IETF106 will be set aside
> to address them
> 
> This starts a two week Working Group Last Call process, and ends on:  15
> November 2019
> 
> thanks
> tim
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

---

From: Brian Dickson <[email-masked]>
Date: Sat, 16 Nov 2019 11:29:38 +0800

Per Benno’s request:

Positive feedback++;
Good document, fits real need, good to go.

Brian

Sent from my iPhone

> On Nov 16, 2019, at 10:43 AM, Benno Overeinder <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 19 Nov 2019 17:20:30 +0800

tjw> This starts a Working Group Last Call for
tjw> draft-ietf-dnsop-multi-provider-dnssec
[...]
tjw> Please review the draft and offer relevant comments.

I think this draft is in good shape. We've been using this as validation
of $DAYJOB procs around this area and have not found any holes in the
draft.

I'd support this as a standard.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Nov 2019 23:41:06 +0000

This document seems complete and well-written. Is is also kinda scary, but that's why we need to document the operational practices in it.

--Paul Hoffman

---

From: Shane Kerr <[email-masked]>
Date: Wed, 20 Nov 2019 16:52:22 +0100

Benno and all,

Overall the document is clear and I hope helpful to organizations 
pursuing a multi-DNS vendor setup who want to use DNSSEC (as all do, I 
am sure).

One minor thing I noticed while looking through the document. It 
mentions the Brazilian ccTLD as background why using a liberal rollover 
is workable:

   In fact, testing by the .BR Top Level
   domain for their recent algorithm rollover [BR-ROLLOVER],
   demonstrates that the liberal approach does in fact work with current
   resolvers deployed on the Internet.

However, the BR-ROLLOVER reference is to a presentation which discusses 
the plans to try a liberal rollover in Brazil, but doesn't actually 
claim that it works. Was there further published research that can 
support this idea?

Cheers,

--
Shane

---

From: Bob Harold <[email-masked]>
Date: Wed, 20 Nov 2019 11:08:08 -0500

On Tue, Nov 19, 2019 at 6:41 PM Paul Hoffman <[email-masked]> wrote:

> This document seems complete and well-written. Is is also kinda scary, but
> that's why we need to document the operational practices in it.
>
> --Paul Hoffman_______________________________________________
>
>
I agree with Paul.  Looks good, kinda scary.

-- 
Bob Harold

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 20 Nov 2019 22:20:30 -0300

Shane,

> claim that it works. Was there further published research that can 

There is a presentation I gave at ICANN-63 with the rollover report.

 * ICANN 63 - Oct/2018                                                                                                  https://static.ptbl.co/static/attachments/191746/1540217948.pdf                                                         
 Audio (English): starting at 57min50s                                                                                  http://audio.icann.org/meetings/bcn63/bcn63-OPEN-2018-10-24-T0636-113-en-DNSSEC-Workshop-1-of--3.m3u 

This was previously reported at dns-operations,

https://lists.dns-oarc.net/pipermail/dns-operations/2018-October/018029.html

Besides of this I think there may be already published references of
this on works of Moritz Muller and Taejoong Chung. They greatly helped
us with the monitoring of the rollover.

> Cheers,

Fred

---

From: Shumon Huque <[email-masked]>
Date: Thu, 21 Nov 2019 10:51:26 +0800

On Thu, Nov 21, 2019 at 9:20 AM Frederico A C Neves <[email-masked]>
wrote:

>  * ICANN 63 - Oct/2018
> https://static.ptbl.co/static/attachments/191746/1540217948.pdf
>
>  Audio (English): starting at 57min50s
>
> http://audio.icann.org/meetings/bcn63/bcn63-OPEN-2018-10-24-T0636-113-en-DNSSEC-Workshop-1-of--3.m3u
>

Thank you Shane and Frederico,

I had actually meant to include the report produced _after_ the BR rollover
was successful. I've made a note to update the draft to replace the current
earlier reference with this later report from October 2018.

> us with the monitoring of the rollover.

If anyone can provide references, we'd be happy to review and consider
including those.

And as a general note on this topic, I want to remind folks that although
the draft says that providers using distinct algorithms can work assuming
validators employ the liberal approach, our strong recommendation is that
the providers all use a common signing algorithm (and common key sizes for
algorithms that support variable key sizes).

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 21 Nov 2019 10:56:42 +0800

On Thu, Nov 21, 2019 at 12:08 AM Bob Harold <[email-masked]> wrote:

>> This document seems complete and well-written. Is is also kinda scary,
>> but that's why we need to document the operational practices in it.
>>
> I agree with Paul.  Looks good, kinda scary..
>

Hi Bob and Paul,

Thank you for your review and support.

Having done prototype implementations, and worked with a vendor that has
implemented these models in production, I personally don't find this very
scary, and am quite confident that it works fine, assuming providers set it
up correctly. Your mileage may vary of course.

Shumon.