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

[Petr Špaček <[e-mail]>]

On 02/17/2017 12:21 AM, Wes Hardaker wrote:
> Wes Hardaker <[e-mail]> writes:
> 
>> 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.
> 
> 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).

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


> Anyway, please do let me know if you think the new text adequately
> 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
> "worst case" timing into the example timeline, but that would make the
> example a bit more messy.

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