Subject: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

From: tjw ietf <[email-masked]>
Date: Thu, 16 Mar 2017 03:16:50 -0400

All

We've had a lot of WG discussion on this, and it seems relevant to do a
formal call for adoption.   If there are outstanding issues raised during
the CfA, time in Chicago will be set aside to have those discussions.

This starts a Call for Adoption for:
 draft-hardaker-rfc5011-security-considerations

The draft is available here:
https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

If there are

This call for adoption ends: 30 March 2017

Thanks,
tim wicinski
DNSOP co-chair

---

From: Petr Špaček <[email-masked]>
Date: Thu, 16 Mar 2017 08:32:06 +0100

On 16.3.2017 08:16, tjw ietf wrote:
> formal call for adoption.   If there are outstanding issues raised
> during the CfA, time in Chicago will be set aside to have those
> discussions. 
> 
> 

Having seen version 03 I support adoption.

Petr Špaček  @  CZ.NIC

> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>

---

From: Shane Kerr <[email-masked]>
Date: Thu, 16 Mar 2017 09:00:56 +0100

Tim,

At 2017-03-16 03:16:50 -0400

> DNSOP, and comments to the list, clearly stating your view.

While from a practical point of view this mostly only useful for ICANN,
it is important to document this issue so that anyone who implements
their own trust anchors understands it, and also so that future DNS
people know that the issue was considered.

I am in favor of adoption.

Cheers,

--
Shane

---

From: william manning <[email-masked]>
Date: Thu, 16 Mar 2017 07:24:34 -0700

this is a useful and needed document.  I support its adoption by the WG.
As a note to the authors, there was a proposed alternate to what became RFC
5011 which addressed some of the same issues as the current draft. It might
be useful to review
https://tools.ietf.org/html/draft-ietf-dnsext-trustupdate-threshold-01
going forward.

/Wm

On Thu, Mar 16, 2017 at 12:16 AM, tjw ietf <[email-masked]> wrote:

> This starts a Call for Adoption for:  draft-hardaker-rfc5011-
> security-considerations
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Bob Harold <[email-masked]>
Date: Thu, 16 Mar 2017 15:13:51 -0400

On Thu, Mar 16, 2017 at 3:16 AM, tjw ietf <[email-masked]> wrote:

> Yes, please adopt, willing to review.

-- 
Bob Harold

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 16 Mar 2017 23:45:45 -0700

william manning <[email-masked]> writes:

> this is a useful and needed document.  I support its adoption by the WG.  As a
> note to the authors, there was a proposed alternate to what became RFC 5011
> which addressed some of the same issues as the current draft. It might be
> useful to review 
> https://tools.ietf.org/html/draft-ietf-dnsext-trustupdate-threshold-01 going
> forward.

Thanks Bill!  And I do remember it (and the discussions at the time).

Note that we're not trying to create a document that modifies the
procedures at all, just trying to create one that ensures people can
securely use the existing one with proper knowledge.
-- 
Wes Hardaker
USC/ISI

---

From: Michael StJohns <[email-masked]>
Date: Mon, 20 Mar 2017 12:00:43 -0400

On 3/16/2017 10:24 AM, william manning wrote:
> this is a useful and needed document.  I support its adoption by the 
> WG.  As a note to the authors, there was a proposed alternate to what 
> became RFC 5011 which addressed some of the same issues as the current 
> draft. It might be useful to review 

Bill -

I went back and re-scanned this and I see no information that bears on 
this problem.   IIRC the draft was abandoned because it *didn't* give 
any timing guidance and was vulnerable (unrecoverable) to single key 
compromises. It gave no guidance on when the *signer* would stop 
publishing and/or revoke a trust anchor which is really the topic of 
Wes' document.

Can you point us to applicable text rather than the complete document?

Later, Mike

>
> /Wm
>
> On Thu, Mar 16, 2017 at 12:16 AM, tjw ietf <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     All
>
>     We've had a lot of WG discussion on this, and it seems relevant to
>     do a formal call for adoption.   If there are outstanding issues
>     raised during the CfA, time in Chicago will be set aside to have
>     those discussions.
>
>
>     <https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/>
>
>     Please review this draft to see if you think it is suitable for
>     adoption by DNSOP, and comments to the list, clearly stating your
>     view.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dnsop>
>
>
>
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 20 Mar 2017 12:18:23 -0400

On 3/16/2017 3:16 AM, tjw ietf wrote:
> All
>
> We've had a lot of WG discussion on this, and it seems relevant to do 
> a formal call for adoption.   If there are outstanding issues raised 
> adoption by DNSOP, and comments to the list, clearly stating your view.

I've no objection to placing this as a WG item for work.

However, as I've indicated to Wes and Warren, it's currently missing the 
point.

Here's the alternate abstract text I proposed to them:

> This document describes the math behind the minimum time-length a DNS 
> zone publisher must wait after publishing a new trust anchor before 
> having a reasonable belief that all operational, well-behaved 5011 
> clients have installed that new trust anchor at their zone trust 
> point.  As publisher guidance, this is also the minimum time the 
> publisher should wait before revoking the complete set of previously 
> published/installed trust anchors and depending on the newly published 
> trust anchor as the sole point of trust and the minimum time the 
> publisher should continuing publishing a revoked key (and its 
> signature) after revocation.

The timing issue you need to resolve is not when you begin providing 
RRSigs with the new key, but when you revoke all of the other keys at 
the trust point.

The document as currently drafted still assumes there is only one trust 
anchor key as steady state.  That's a) a bad assumption, and b) a bad 
operational policy.

Mike

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 27 Mar 2017 23:09:38 +0200 (CEST)

I support this.

And found a nit, the document says:

   The most confusing element of the above equation comes from the "3 *
   (DNSKEY RRSIG Signature Validity) / 2"

but the formula just before doesn't include "3 *" anywhere in it.

Cheers,
Ondrej

--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

----- Original Message -----
> From: "tjw ietf" <[email-masked]>
> To: "dnsop" <[email-masked]>
> Sent: Thursday, 16 March, 2017 08:16:50
> Subject: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

> All
> 
> We've had a lot of WG discussion on this, and it seems relevant to do a formal
> call for adoption. If there are outstanding issues raised during the CfA, time
> in Chicago will be set aside to have those discussions.
> 
> 
> [
> |
> ]

---

From: tjw ietf <[email-masked]>
Date: Thu, 30 Mar 2017 17:28:57 -0500

Hi

The Call for Adoption has ended and there was support to adopt this
document and work out the handful of issues brought up.  Thanks everyone
for comments, etc.

If the authors can upload a new version we;ll get that one squared away.

thanks
tim/suzanne