Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations

From: Wes Hardaker <[email-masked]>
Date: Wed, 06 Sep 2017 09:05:44 -0700

Matthijs Mekking <[email-masked]> writes:

Thanks for all your points, and I've gone through and handled them all
in the text (including discussing that we update 7583 per your request).

> 2. waitTime only adds one queryInterval, while Itrp adds two. I believe
> to be safe on the publishing side, two queryIntervals is needed. RFC
> 7583 explains:
>
>    A validator will treat it as a trust anchor the next
>    time it retrieves the RRset, a process that can take up to another
>    queryInterval (the third term).

This is the one that had me think with a whiteboard for a while.  If I
can sum it up differently, the problem is that 30 days may not be a
factor of the queryInterval.  Thus:

    N * queryInterval >= 30

Where N is the number of queries to get somewhere over 30 days.

So Irtp is waiting an extra queryInterval to account for this
possibility.

Mathematically, I think the actually time needed to wait is 30 %
queryInterval, which may actually be 0 in some cases and just shy of
queryInterval in others.  Sound about right?

> 4. Both definitions (Itrp and waitTime) don't really take into
> consideration the retryTime defined in RFC 5011. Perhaps that can be
> used for defining the extra safety margin.

I'll have to add some text about that.  I don't think we can solve the
case for broken networks, though.  But it's an important point to bring up.

-- 
Wes Hardaker
USC/ISI

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 11 Sep 2017 13:59:40 +0200

Wes,

> factor of the queryInterval.  Thus:

But it is:

queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
   1/2*RRSigExpirationInterval))

Since the 5011-enabled resolver should see at least two queries with the
new trust anchor, the 15 days (30/2) is in the above equation defined in
RFC 5011.

>     N * queryInterval >= >

Sure, but N does not need to be higher than two, and in that case:

    2 * queryInterval = MAX(2 hr, MIN (30 days, OrigTTL,
RRSigExpirationInterval))

In other words, never more than 30 days.

> So Irtp is waiting an extra queryInterval to account for this

Right, and since it is a possibility, it should be taken into account.

An important observation is that once the add hold-down timer expires,
the new key will be added as a trust anchor *only* the next time the
validated RRset with the new key is seen at the resolver.

This is the reason why the second queryInterval must be part of the
equation.

> queryInterval in others.  Sound about right?

I am sorry, I don't understand this logic, can you elaborate?

The way I see it, queryInterval is always at minimal 1 hr and at most 15
days (not taking into account retryTime).

Best regards,
  Matthijs

---

From: Michael StJohns <[email-masked]>
Date: Mon, 11 Sep 2017 12:49:24 -0400

Wes/Warren - you still owe a response on the following.

On 7/19/2017 4:42 AM, Michael StJohns wrote:
> On date time vs intervals - I finally realized why Wes and I are 
> somewhat disconnected on this.
>
> 5011 was written as the protocol for the resolver and is totally 
> interval driven.   (E.g. query and retry timers are set and fire based 
> on when the resolver performs an action).
>
> This document is being written for the zone publishers, and the 
> process of publication is task driven and has humans as protocol 
> element timers.  The actual publication of a DNSSEC RRSIG is divorced 
> from both the date/time of creation and the RRSig's actual inception 
> and expiration dates.  While there is a defined interval between 
> inception and expiration, expiration occurs at a fixed point in time 
> and that point in time is independent from the interval between 
> publication and receipt by the client.
>
> In other words - the correct (or at least better and less subject to 
> being misunderstood) way of describing the various points in time the 
> publisher should do something is by referencing the fixed point in 
> time (expiration) where both publisher and client agree that something 
> happens and then figuring other fixed points in time from that 
> point.   Or to restate it again - "A publisher must wait until June 
> 5th 2010" will always evaluate to the same date and time regardless of 
> who calculates it and when they calculate it; "A publisher must wait 
> 30 days" will not.
>
>
> So :
> "
> publicationAddWaitInterval :: = MAX (30 Days, originalTTL of NEW 
> DNSKEY RRSet) + MAX ( all calculated queryIntervals for OLD and new 
> RRSets)  + addSlopInterval
> queryInterval ::= MAX (1 hour, MIN (
>                                                 15 days,
>                                                .5 * expirationInterval 
> DNSKey RRSet,
>                                                .5 * originalTTL DNSKey 
> RRSet)
>                                           )
>
> expirationInterval :: = expirationDate - inceptionDate
> addSlopInterval ::= 2 * MAX(originalTTL of any  DNSKEY RRSet valid 
> during the transition process)
>
> The publicationAddWaitDateTime  is the date and time on which the 
> publisher can assume that most of the 5011 capable resolvers have 
> accomplished the addition of the new trust anchor to their trust 
> anchor sets.  That date is the addHoldDownTimeInterval AFTER the 
> latest in time signature expiration date of any RRSet without the new 
> key.  This includes both published and unpublished RRSets. Publishers 
> should refrain from creating or publishing DNSKEY RRSets signed 
> exclusively by a new key until after this date. Specifically, the 
> inception date of such an RRSig should be later than the 
> publicationAddWaitDateTime"
>
> The addHoldDownTimeInterval above differs from what is in 5.1 section 
> 2.4.1 in that this is the publishers view of when the new trust anchor 
> is accepted by the resolver which may differ from a specific resolvers 
> view (due to when things are actually sent and received).  Section 
> 2.4.1 has to be combined with the text in section 2.2 which states 
> that the key isn't added until after the next time it is seen after 
> the expiration of the add hold down. Also, the queryInterval term of 
> this calculation should be the maximum of any DNSKEY RRSet seen during 
> the transition - it's possible that the publisher may reduce the 
> intervals or increase the intervals between RRSets and this provides 
> the publisher with the worst case value that any given resolver should 
> be using.
>
>
> Let's not confuse resolver numbers with publisher numbers and spend a 
> bit of time to get the language clear correct and implementable.
>
> Mike
>
>
>
>
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 11 Sep 2017 14:22:23 -0400

> queryInterval in others.  Sound about right?

*bleah*  This is the problem with trying to do the publisher math from 
the resolver's point of view.

In the following lower case terms are intervals, uppercase terms are 
date/times.  The difference between two date/times is an interval. The 
sum of an interval and a date/time is a date/time.

A given resolver - absent an attack (and missing packets) - installs a 
new trust anchor at this point in time (assuming the new stuff was 
published after LastQueryTime)

    LastQueryTime + queryInterval + addHoldDownTime + queryInterval.

With an attack (but absent missing packets), the new trust anchor is 
installed   at this point in time:

    RRSigExpirationTime + (queryInterval - MIN(0, RRSetExpirationTime -
    LastQueryTimePriorToRRSetExpiration )) + addHoldDownTime + queryInterval

The publisher, to calculate how long it should wait before assumes that 
most resolvers have installed the new trust anchor has to be able to 
calculate both queryInterval and addHoldDownTime and then take a SWAG as 
to how much longer to wait.  So assuming worst case we

Substitute queryInterval for

    (queryInterval - MIN(0, RRSetExpirationTime -
    LastQueryTimePriorToRRSetExpiration))

(Assuming that the RRSetExpiration happens infinitesimally after to the 
expiration of the query timer). That gets you the latest time the 
resolver might install a new trust anchor (without retries):

    RRSigExpirationTime + queryInterval + addHoldDownTime + queryInterval.

queryInterval starts as the 5011 formulation: queryInterval = MAX(1 hr, 
MIN (15 days, 1/2*origTTL, 1/2*  rrSigExpirationInterval))  but we have 
to deal with a possible disconnect here.  The notation is made that 
maxOldRRSigExpirationInterval is the maximum rrSigExpiratonInterval of 
the DNSKeyRRSets published prior to the RRSigExpirationTime.    The 
reason for this is to deal with the case where the publisher changes the 
rrSigExpirationInterval for the new DNSKeyRRSets and where it might be 
unclear which of multiple possible queryIntervals the resolver is using.

So:

    publishersQueryIntervalEstimate ::= MAX (1hr, MIN (15 days, 1/2*
    origTTL, 1/ * maxOldRRsigExpirationInterval))

addHoldDownTime starts as the 5011 formulation: "The add hold-down time 
is 30 days or the expiration time of the original TTL of the first trust 
point DNSKEY RRSet that contained the new key, whichever is greater." 
and gets converted into an actual formula:

    publishersAddHoldDownEstimate ::= MAX (30 days, origTTL).

So putting it all together we get:

    OldRRSigExpirationTime ::= the latest expiration date of an RRSig
    over an DNSKey RRSet which did not contain the new anchor.

    PublishersAddCompleteEstimatedDate ::= OldRRSigExpirationTime + 2 *
    publishersQueryIntervalEstimate + publishersAddHoldDownEstimate

That gets us a date on which well behaving resolvers should have gotten 
the word. But we need safety so:

    PublishersAddCompleteSafeDate ::= PublishersAddCompleteEstimatedDate
    + publishersSlop.

For want of a better value we use publishersSlop ::= 2 * 
publishersQueryIntervalEstimate making the final formula:

    PublishersAddCompleteSafeDate ::= OldRRSigExpirationTime + (4 *
    publishersQueryIntervalEstimate) + publishersAddHoldDownEstimate

So assuming:

    Today ::= 11 September 2017, Noon UTC

    OldRRSigExpirationTime ::= 18 September 2017, Noon UTC

    maxOldRRSigExpirationInterval (from the draft 5.1): 10 days.

    origTTL ::= 1 day

We get:

         publishersQueryIntervalEstimate:  MAX (1 hr, MIN (15 days, 12
    hrs, 5 days)) or 12 hrs.
         publishersAddHoldDownEstimate: MAX (30 days, 1 day) or 30 days.
         PublishersAddCompleteEstimatedDate: 201709181200 + 1 day + 30
    days or 201710191200
         PublishersAddCompleteSafeDate: 201709181200 + 2 days + 30 days
    or 201710201200

The actual interval to wait is PublishersAddCompleteSafeDate - Today or 
201710201200 - 201709111200 or 38 days assuming that you publish as soon 
as you sign.  (which is generally a bad assumption and why I keep 
pushing to use dates not intervals as the results).

Using instead some larger values:

    Today ::= 11 September 2017 Noon UTC
    OldRRSigExpirationTime ::= 30 September 2017 Noon UTC
    maxOldRRSigExpirationInterval:  45 days
    origTTL ::= 7 days

We get:

    publishersQueryIntervalEstimate: MAX (1 hr, MIN (15 Days, 3.5 days,
    22.5 days)) or 3.5 days
    publishersAddHoldDownCompleteEstimatedDate: MAX (30 days, 7 days) or
    30 days
    PublishersAddCompleteEstimatedDate:  201709301200 + 7 days + 30 days
    we get 201711061200
    PublishersAddCompleteSafeDate: 201709301200 + 14 days + 30 days we
    get 201711131200

Note that the safe dates can be calculated without reference to the 
current date, and without a need to back calculate an interval.

Mike

> case for broken networks, though.  But it's an important point to bring up.
Assume the worst case - that a resolver never goes into the fast retry 
mode.  Then you can just ignore the retryTime in favor of queryTime as a 
slop term.

Mike

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 12 Sep 2017 16:41:23 -0700

> days (not taking into account retryTime).

In the end, the first (newly valid) time the validator queries for and
gets the new dnskey will be N minutes after the signature expiration
time.  The validators timer will start at that point.  Because
queryInterval is always equal to or less than 15 days, the validator
will always see the key twice before the 30 day window is up.  So if 30
days is a multiple of the query Interval (eg, 15 days, or 5 days) then
the first time the validator will see the key after the 30 day window is
N minutes after the expiration time plus 30 days.  Thus only 1 query
interval needs to be added in this ideal case.

The less than ideal case is when 30 isn't evenly divisible by the
queryInterval (eg, 7 days).  At which point the first time the validator
will see the new key after the (sig_exp + N + 30 days) mark will be at
(sig_exp + N + 30 days + remainder(30 days / 7)).  So we don't need to
add in a full queryInterval to cover the offset and can calculate it
instead.

(that being said, I put "you might pick 2x for simplicity" into the draft)
-- 
Wes Hardaker
USC/ISI