Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt

[Wes Hardaker <[e-mail]>]

Michael StJohns <[e-mail]> writes:

> Much improved - but still some disconnects (all review is de novo):

That's Mike.  All good comments.  I've attached responses and actions
(or inactions) below and will push a new version shortly as well.

Wes Hardaker


Table of Contents
_________________

1 DONE In Abstract - insert "by the publisher" after "must be followed" -
2 DONE Section 2 - first para - "from the DNSKEY publication and
3 DONE in 3 - lastSigExpirationTime - replace the first sentence  with "The
4 TODO in 3 - sigExpirationTimeRemaining - two items:
5 DONE in 5.1.1 T+10 - replace "they have now expired" with "the signatures
6 WONTDO Delete 6.1.4 - activeRefreshOffset -  its a nonsensical value that is
7 WONTDO 6.2.1 - replace activeRefreshOffset with activeRefresh - worst case
8 WONTDO fix 6.2.1.1 delete the term for addHoldDownTime % activeRefresh - the
9 WONTDO In 6.2.2 - same changes as for 6.2.1 and 6.2.1.1 (e.g. get rid of
10 DONE Section 6.3 has one too many activeRefresh terms in both formulas -
11 WONTDO Guidance about key compromise
12 DONE Appendix A - fix the calculations to match up with the section 6 formulas.


1 DONE In Abstract - insert "by the publisher" after "must be followed" -
=========================================================================

  this is clear later, but should be clear in the abstract.


2 DONE Section 2 - first para - "from the DNSKEY publication and
================================================================

  revocation's point of view" is unusual phrasing.  I'm not sure how a
  publication or revocation has a point of view.  I think you meant from
  the trust anchor publisher or SEP DNSKEY publisher's point of view?

  + Response: I did indeed mean SEP publisher; fixed


3 DONE in 3 - lastSigExpirationTime - replace the first sentence  with "The
===========================================================================

  latest value (i.e. the future most date and time) of any RRSig
  Signature Expiration field  covering any DNSKEY RRSet containing only
  the old trust anchor(s) that are being superseded." - This may still
  need wordsmithing or expansion.


4 TODO in 3 - sigExpirationTimeRemaining - two items:
=====================================================

  "latestSigExpirationTime" -> lastSigExpirationTime.  and measured from
  when?   I think its "when the addWaitTime calculation is run" or
  "lastSigExpirationTime - now"

  + Response: I think it's fairly self evident from the text that it's
    "when used", which is indeed at least during addWaitTime
    calculation.  But it's more conceptual and 'the amount of time
    remaining' I think is pretty clear to mean "from now".  I thought
    about adding something like "from now" into the sentence, but that
    didn't seem better to me and added unneeded or complexity to the
    sentence.  Suggestions?


5 DONE in 5.1.1 T+10 - replace "they have now expired" with "the signatures
===========================================================================

  have now expired" -  clarify context.


6 WONTDO Delete 6.1.4 - activeRefreshOffset -  its a nonsensical value that is
==============================================================================

  only valid from the resolver's point of view.   For a given
  publisher/authoritative server - there will be as many
  activeRefreshOffsets as there are resolvers so the publisher must
  assume the worst case of activeRefresh.

  + Response: I disagree here.  This was put in after a discussion with
    Matthijs Mekking to specifically address the case where the polling
    period may not end up right in time-step with the addHoldDownTime.
    The end result is that when a RFC5011 resolver is polling at a
    different frequency based on the activeRefresh time.  We are
    defining a minimum mathematically defined safety value and this
    value is calculatable, so it should remain.  There is a hint of
    guidance text that says you can set it to activeRefresh for
    simplicity if you want.  But the math-line is before a full second
    activeRefresh.  But the value itself needs to be included to account
    for the odd frequency slippage.

    TL;DR: this isn't a guidance document, it's a mathematical line
    document


7 WONTDO 6.2.1 - replace activeRefreshOffset with activeRefresh - worst case
============================================================================

  value. (Wait Timer Based Calculation)


8 WONTDO fix 6.2.1.1 delete the term for addHoldDownTime % activeRefresh - the
==============================================================================

  "2 * activeRefresh" in the previous term covers both the activeRefresh
  interval at the beginning of the acceptance period and the
  activeRefresh interval at the end.


9 WONTDO In 6.2.2 - same changes as for 6.2.1 and 6.2.1.1 (e.g. get rid of
==========================================================================

  activeRefreshOffset throughout).


  ,----
  |                         v          activeRefresh v    
  | addHoldDownTime                 v    activeRefresh v  safetyMargin  v
  | 
  | |-----------------------|-------------------------------------|-------------------------------------|--------------------------|----------------|
  | 
  |  lastSigExpirationTime^^^                 acceptanceStarts ^^^      
  | acceptance begins to complete^^            earliestSafe^^^
  `----

  After the second activeRefresh interval all of the well behaved and
  well connected resolvers should have the new trust anchor. The
  safetyMargin adds some space for poorly behaving or intermittently
  connected resolvers or those with some drops in queries.


10 DONE Section 6.3 has one too many activeRefresh terms in both formulas -
===========================================================================

  here are the corrected ones:

  remWaitTime = sigExpirationTimeRemaining + activeRefresh +
  safetyFactor

  remWallClockTime = lastSigExpirationTime + activeRefresh +
  safetyFactor

  Basically, assuming no attacker, and no drops, all well-behaved
  resolvers will see the revocation after one activeRefresh interval
  from the time of publication.  Add the safety factor to take care of
  the slackers.  This is a fine value for normal revocations where
  you're pretty sure that the key hasn't been compromised.

  There is no hold-time timer for revocation - they take effect
  immediately upon receipt and validation.


11 WONTDO Guidance about key compromise
=======================================

  In the case of a key compromise, I would suggest that the revoked key
  be published for the same interval as you would use for adding a new
  trust anchor.  (But of course, this won't actually matter all that
  much if you only have a single trust anchor....)

  + Good advice to put in an general advice document in the future


12 DONE Appendix A - fix the calculations to match up with the section 6 formulas.
==================================================================================

-- 
Wes Hardaker
USC/ISI