Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

From: Warren Kumari <[email-masked]>
Date: Fri, 3 Feb 2017 21:14:03 -0500

Hi all,

Was and I have updated this document to make it clearer and more
readable. Please take a read and let us know if any parts are unclear,
if you have any other feedback, etc.

Is this close to done?
W

On Fri, Feb 3, 2017 at 6:29 PM,  <[email-masked]> wrote:
>
> A new version of I-D, draft-hardaker-rfc5011-security-considerations-02.txt
> has been successfully submitted by Warren Kumari and posted to the
> IETF repository.
>
> Name:           draft-hardaker-rfc5011-security-considerations
> Revision:       02
> Title:          Security Considerations for RFC5011 Publishers
> Document date:  2017-02-02
> Group:          Individual Submission
> Pages:          8
> URL:            https://www.ietf.org/internet-drafts/draft-hardaker-rfc5011-security-considerations-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/
> Htmlized:       https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hardaker-rfc5011-security-considerations-02
>
> Abstract:
>    This document describes the math behind the minimum time-length that
>    a DNS zone publisher must wait before using a new DNSKEY to sign
>    records when supporting the RFC5011 rollover strategies.
>
>
>
>
> 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
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Shane Kerr <[email-masked]>
Date: Mon, 6 Feb 2017 13:11:53 +0100

Warren,

I am still wondering about the:

   3 * (DNSKEY RRSIG Signature Validity) / 2

Term in the draft, which I see survived the update.

Why is this not just the DNSKEY RRSIG Signature Validity? In principle
once the signature has expired it cannot be used to replay the old
DNSKEY RRset right?

Cheers,

--
Shane

At 2017-02-03 21:14:03 -0500
Warren Kumari <[email-masked]> wrote:

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

---

From: Bob Harold <[email-masked]>
Date: Mon, 6 Feb 2017 09:17:45 -0500

On Fri, Feb 3, 2017 at 9:14 PM, Warren Kumari <[email-masked]> wrote:

> > URL:            https://www.ietf.org/internet-
> drafts/draft-hardaker-rfc5011-security-considerations-02.txt
> > Diff:           https://www.ietf.org/rfcdiff?
> url2=draft-hardaker-rfc5011-security-considerations-02
> >
> > Abstract:
> <https://www.ietf.org/mailman/listinfo/dnsop>

Thanks for your work on this.  Some minor formatting issues:

Table of contents:
sections 5 and 5.1 have large blank space in middle
(as formatted at
https://www.ietf.org/id/draft-hardaker-rfc5011-security-considerations-02.txt
)
section 8 is wrapped unnecessarily

Section 3:
large space in first line

Section 5:
"poising" -> "poisoning"

Section 5.1.1
"(a new)" -> "(anew)"

Section 6
47 - 35 = 12 days (not 11)?

-- 
Bob Harold

---

From: Petr Špaček <[email-masked]>
Date: Mon, 6 Feb 2017 17:04:38 +0100

> once the signature has expired it cannot be used to replay the old

Shane was faster than me, I'm also wondering how 3/2 got here.

I expect that 3/2 = 2/2 to avoid replay attack + 1/2 from RFC 5011.

In any case, it would be awesome if each component in section 6 had own
explanation what role the particular component plays in the equation.

-- 
Petr Špaček  @  CZ.NIC

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 16 Feb 2017 08:25:19 -0800

> Shane was faster than me, I'm also wondering how 3/2 got here.

Yep.  And had we been smarter and written it down when we first wrote
it, there wouldn't be this question.  Sadly, we had a reason and now
Warren and I have to remember it.  We spent a long time wandering around
random streets on Berlin and the 3/2 was a sudden aha (oh no) moment if
I recall.

Anyway, we'll revamp the document again in the near future with the
terms better spelled out, because I agree they need to be.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 16 Feb 2017 08:33:59 -0800

> Thanks for your work on this.  Some minor formatting issues:

Odd.  I think *someone* wasn't using a real editor (*cough*emacs*cough*)
and it inserted some odd white space into XML components.

Thanks for the catches; fixed on all accounts.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 16 Feb 2017 09:29:15 -0800

Wes Hardaker <[email-masked]> writes:

> Sadly, we had a reason and now Warren and I have to remember it.

Fortunately, after a quick conversation we've recovered the reason.
Publishing a new version with a break-out explanation shortly.  The 3/2
is absolutely is needed.
-- 
Wes Hardaker
USC/ISI

---

From: Warren Kumari <[email-masked]>
Date: Thu, 16 Feb 2017 12:43:19 -0500

> and it inserted some odd white space into XML components.

... and it seems that that someone was Wes :-P
W

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 16 Feb 2017 15:19:52 -0800

> ... and it seems that that someone was Wes :-P

Yeah...  I'll go eat my shoe now.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 16 Feb 2017 15:21:23 -0800

> Publishing a new version with a break-out explanation shortly.  The 3/2

I've published -03 which adds new text just below the equation
explaining the components (and the equation got more complex to match
the complexity of 5011).

Anyway, please do let me know if you think the new text adequately
explains the problem to you.  I probably need to go back and insert the
"worst case" timing into the example timeline, but that would make the
example a bit more messy.
-- 
Wes Hardaker
USC/ISI

---

From: Petr Špaček <[email-masked]>
Date: Fri, 17 Feb 2017 12:59:58 +0100

> explaining the components (and the equation got more complex to match

Thanks! The equation seems more complex at first glance but it is way
more understandable for me.

When reading the quote from the RFC5011 "Active Refresh" requirements, I
realized the equation is not complete without:
  MAX(MIN(...), 1 hour)

I.e. the waitTime would be too short for quick turn-around zones. This
is probably not that important for practical deployment but it gets
veeery important when transforming RFC text to a compliance test.

Please add the MAX(), it will help someone in future. (I'm just trying
to write compliance test for RFC 6672 ...)

> explains the problem to you.
The explanation seems good to me. Just a few comments about the text:

It would be easier to understand for me if this paragraph was split into
two (1st the constraint + 2nd prelude for analysis):
/the matter/
  The important timing constraint that must be considered is the last
  point at which a validating resolver may have received a replayed the
  original DNSKEY set (K_old) without the new key.  It's the next query
  of the RFC5011 validator that the assured K_new will be seen.

/prelude for analysis/
  For
  the following paragraph, we use the more common case where (DNSKEY
  RRSIG Signature Validity) is greater than (original TTL for the
  DNSKEY RRSet), although the equation above takes both cases into
  account.

Moreover the /prelude for analysis/ seems little bit confusing. What
about something along these lines?

/replacement prelude for analysis, preferably as separate paragraph/
  The interval used by RFC5011 resolver is determined by lesser of
  (DNSKEY RRSIG Signature Validity) or (original TTL for the DNSKEY
  RRSet). Following text assumes that (DNSKEY RRSIG Signature Validity)
  is smaller of the two.

/original text continues here/
  Thus, ...

> I probably need to go back and insert the

It seems sufficient to me to keep the analysis in (current) section 6.
Maybe just a forwad-reference would suffice.

Thank you for the clarification!

-- 
Petr Špaček  @  CZ.NIC