Subject: [DNSOP] [[email-masked]] New Version Notification for draft-hardaker-dnsop-intentionally-temporary-insec-00.txt

From: Wes Hardaker <[email-masked]>
Date: Sun, 21 Feb 2021 13:06:34 -0800

Here's another document for folks to think about wrt its contents.  I'd
love feedback.  Or if the WG is brave, adoption.

-------------------- Start of forwarded message --------------------
From: [email-masked]
To: "Wes Hardaker" <[email-masked]>
Subject: New Version Notification for draft-hardaker-dnsop-intentionally-temporary-insec-00.txt
Date: Sun, 21 Feb 2021 12:42:01 -0800

A new version of I-D, draft-hardaker-dnsop-intentionally-temporary-insec-00.txt
has been successfully submitted by Wes Hardaker and posted to the
IETF repository.

Name:		draft-hardaker-dnsop-intentionally-temporary-insec
Revision:	00
Title:		Intentionally Temporarily Insecure
Document date:	2021-02-21
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/archive/id/draft-hardaker-dnsop-intentionally-temporary-insec-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hardaker-dnsop-intentionally-temporary-insec/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-intentionally-temporary-insec
Htmlized:       https://tools.ietf.org/html/draft-hardaker-dnsop-intentionally-temporary-insec-00

Abstract:
   Performing DNSKEY algorithm transitions with DNSSEC signing is
   unfortunately challenging to get right in practice without decent
   tooling support.  This document weighs the correct, completely secure
   way of rolling keys against an alternate, significantly simplified,
   method that takes a zone through an insecure state.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-------------------- End of forwarded message --------------------

-- 
Wes Hardaker
USC/ISI

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 22 Feb 2021 20:25:35 +0100

Hello.

I'm certainly not fond of trying to call this "best practice".
I'd rather try persuading people to either improve such tooling or 
switch production to another one, but I understand that in real life 
there are cases where the proposed approach may be considered a better 
choice than a proper rollover.

--Vladimir @ knot-resolver.cz

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Feb 2021 13:20:38 -0500

I also think that this is not appropriate as a Best Practice.  I would
suggest reversing this draft to make it operational guidance to
implementers about how to enable compliance with RFC 6781 Section 4.1.4.

On Mon, Feb 22, 2021 at 2:26 PM Vladimír Čunát <[email-masked]>
wrote:

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

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 25 Feb 2021 10:44:43 -0800

Ben Schwartz <bemasc=[email-masked]> writes:

> I also think that this is not appropriate as a Best Practice.  I would suggest
> reversing this draft to make it operational guidance to implementers about how to
> enable compliance with RFC 6781 Section 4.1.4.

Thanks for the feedback from both of you.

I think I could certainly argue it could be considered best practice
(IE, it is best practice to update your algorithm -- it's time to move
away from RSASHA1), and if this is the only way you can pull it off....

But, let's assume we want to remove the notion of "best practice", then
it leaves what to publish it as.  Maybe informational would leave
everyone more comfortable?
-- 
Wes Hardaker
USC/ISI

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 25 Feb 2021 14:13:50 -0500

The most interesting informational element, in my view, would be guidance
on how to detect buggy implementations that will create this problem.  (Set
up a test zone and a test resolver and ...?).  I think the best practice is
probably to migrate to a better implementation before rolling the algorithm.

On Thu, Feb 25, 2021 at 1:45 PM Wes Hardaker <[email-masked]> wrote:

> suggest

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 25 Feb 2021 18:04:09 -0200

> On Feb 25, 2021, at 5:13 PM, Ben Schwartz <[email-masked]> wrote:
> 
> The most interesting informational element, in my view, would be guidance on how to detect buggy implementations that will create this problem.  (Set up a test zone and a test resolver and ...?).  I think the best practice is probably to migrate to a better implementation before rolling the algorithm.

The sentiment is certainly noble, but it is not infrequently far
from the reality imposed by the concrete tools that, for better
or worse, are the ones at many users' disposal.

For example, ietf.org is signed manually once a year!  This is
done via some homebrew combination of scripts.  And much as it
may be nice to tell them to upgrade to BIND 9.16 and turn on a
key management policy that takes care of al the little details
automatically,

  https://dilbert.com/strip/1995-06-24

there may well be reasons why that may not be in the cars for
some time.

So I don't think that just sweeping the problem under the rug
is realistic.  I think "informational" is a reasonable choice.

-- 
	Viktor.

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 25 Feb 2021 16:38:00 -0500

> probably to migrate to a better implementation before rolling the algorithm.

Sometimes the bug is an absent operator on the other end of the transfer.
Or an uncooperative one, which RFC 6781 doesn't really address.  I have a
zone I'm planning a move for where the only way it's going to get done,
without going through a bogus state, is by going through an insecure
state.

I'd be extremely uncomfortable labelling that kind of transfer as a best
practice, but it's operational reality that it's going to happen, and it
probably wouldn't hurt to have a document out there explaining how to do it
the best way possible.  Provided, of course, that it's heavily laden with
caveats pointing to all the more secure procedures documented that should
be ruled out first.