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

[Michael StJohns <[e-mail]>]

On 11/29/2017 5:29 PM, Wes Hardaker wrote:
> [e-mail] writes:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.  This draft is a work item of the Domain Name System
>> Operations WG of the IETF.
> FYI, this contains the restructuring talked about during IETF100/dnsop
> as well the new safetyMargin concepts proposed by MSJ.  I haven't done a
> complete double check on all my restructuring yet, so for the chairs
> especially: there will likely be a -09 very soon ready for second WGLC,
> but not this one.


Hi -

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

In Abstract - insert "by the publisher" after "must be followed" - this 
is clear later, but should be clear in the abstract.


in 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?

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.

in 3 - sigExpirationTimeRemaining - two items: "latestSigExpirationTime" 
-> lastSigExpirationTime.  and measured from when?   I think its "when 
the addWaitTime calculation is run" or "lastSigExpirationTime - now"

in 5.1.1 T+10 - replace "they have now expired" with "the signatures 
have now expired" -  clarify context.

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.

In 6.2.1 - replace activeRefreshOffset with activeRefresh - worst case 
value.

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.


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.


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.

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


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


Later, Mike