Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4571331CB for ; Mon, 11 Sep 2017 11:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.402 X-Spam-Level: ** X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GucNmkxnEw9O for ; Mon, 11 Sep 2017 11:22:28 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C651331C1 for ; Mon, 11 Sep 2017 11:22:27 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id b23so20416988qkg.1 for ; Mon, 11 Sep 2017 11:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=kOz2X2VFyN1q+i3h7HSqRpGe0bHiQPuwsUgqT4KLZAo=; b=NkOsQzTyvLTM7urISNawxY1elSCwZE2tvUfPk6USoDnnu8gzwjVcK4HvaTGF8DkkhZ NzkLxrX1LKG5zhbdBk0AkAYA8QbxkJ7u7kkOmOM/E51XkBVEoA5RDIYM/gsu2tRB8y8e Up3kDboIanZuYa1xzdoKT/h2KqhBHUj/W1PDBp1nrIgA/ZY79lAM98Z5pE0I4Xt8FSqs jOTNtS6b7oSUvvAw9tR6ZluSz4DkhAyLGAOMT2SWzZymNhwp9fSZ6ENha5sG7a94rx+Z PwVBPXDKrOTiz+BAonxR8KD2l4em2rGdKoLyPiq3jQomoshrmrZsyD9nhLUoE3E94MsY xFJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=kOz2X2VFyN1q+i3h7HSqRpGe0bHiQPuwsUgqT4KLZAo=; b=ex5iX/gVyBQYFvCO7MbJzXkq4Psr7NvCrDalhEo4JaT27s9zCr/BYIUxsW9sbqQSO7 p31h6zJ66fUYRbNH8/f5HmMJaqxRLLlS2IEJqaBTkzoDRc9J2G4X/OWIz7Q6w9UPE0Wb 9bHSlJQRNiHG9mcrIr3Ojsi/CvD5FxMOZTPA2m82iZvXrCeekS4a9JBQl+ygbK9NLvEY G9CjsABPWUAXdZlpu0QQ0bEFSTJy02/2DCv8a6/zOCZTXOWOKgI7bVP2+CC/YtbELYV9 AA9PF4PcvOvkZ7i6KyJJPGq1NV57iZZFVeEFYLqnX4EQiN0/7aJtiYqUt+5L+NHs9Mzr lf7w== X-Gm-Message-State: AHPjjUhbLx0rsOLzYd6wY8WQ8b+GX/FLxSUvXLQQJfTU10rcaaamNIkD f/mD4bBWGK3ER7g2S0k= X-Google-Smtp-Source: AOwi7QD7yoSAP2xNXlm/Se1eg97qdR8cOWRVn2AK/mRdydhJ0zQ/k6/kb3CqyEZY3HHPHYUw+EPUWQ== X-Received: by 10.55.140.132 with SMTP id o126mr15611605qkd.126.1505154146468; Mon, 11 Sep 2017 11:22:26 -0700 (PDT) Received: from [192.168.1.117] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id j206sm6370277qke.7.2017.09.11.11.22.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 11:22:25 -0700 (PDT) To: dnsop@ietf.org References: <7d425067-84ff-2471-d39a-0c3a20c0116c@pletterpet.nl> From: Michael StJohns Message-ID: Date: Mon, 11 Sep 2017 14:22:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1A2847A2F9CC7944810D6E47" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 18:22:30 -0000 This is a multi-part message in MIME format. --------------1A2847A2F9CC7944810D6E47 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/6/2017 12:05 PM, Wes Hardaker wrote: > Matthijs Mekking 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? *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 > >> 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. > 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 --------------1A2847A2F9CC7944810D6E47 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/6/2017 12:05 PM, Wes Hardaker wrote:
Matthijs Mekking <matthijs@pletterpet.nl> 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?

*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











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.

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


--------------1A2847A2F9CC7944810D6E47--