Re: [DNSOP] 5011-security-considerations and the safetyMargin

Bob Harold <> Fri, 17 November 2017 05:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F0E4127B5A for <>; Thu, 16 Nov 2017 21:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K0I_ZAPrfCpH for <>; Thu, 16 Nov 2017 21:27:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74FF81286B2 for <>; Thu, 16 Nov 2017 21:27:09 -0800 (PST)
Received: by with SMTP id u70so1133446pfa.7 for <>; Thu, 16 Nov 2017 21:27:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xyieop/eVyzMlE+wqWe4R/61MvVPv8APgOa9KADFROE=; b=jRa+MsJaz1bGFvl1Im1QqzFF7UVQc61lvRx1CIJjWVnBBIpDKVdq3Xn/G/NGBvyHSs v1FhtpzFMx4rFrlBtzl1/7s9uLMJZ9OitD1BauQGuke5ZP56TCnWmlfdeE8GTNeWelPu LrPYPMFPTMW2vxWjW1zgPIONBExfwhfVQpVuSlOIn+yJCFOeaR6ejn/m740p7sbHlBFa TMGIjfSj+cqJlZC9wUQfkZVGUGpDyVXmp5qxn1fOwxP0jAxk69GHtT4X7E+qkcTfqx4E st0fcHY017gnYOJeyxtO9zNHZAEJ56qaHI50cfwOSLg98/6fr8IbNrCTWCJE+d5ySh1Z QuJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xyieop/eVyzMlE+wqWe4R/61MvVPv8APgOa9KADFROE=; b=dOWzE/au/dZ/TTNserXgTkE3c4IPm1ffamdiugIa2loi+iJ9wpXUTH1EAt88xPYEIS ZH/5VNW6awDrd+FIGqhQHPlL/U+aW1ovbYQbKMCzm4MKWANQ4eytqTBazZfk3u2jSRFi 5ObOP7HLfwxI8qlycqRk1ZwlbhwgRiQIOcyBjiu7sbt1/UPijTK5AFSnp0sHDAobsc+t cWEetWMA8PNWr4BDrIghKL9MNpfgrRtvbY9LwZ5mQ0s3plvZt0Dn9tblIrm7bX8ARKzg 882uUlVRO851RCjrtSvnLsJL06VraYXCDRyo44qCHoJ4oYVGnL0Wa3Ahzw9Fs6Gi9Zs0 ekHA==
X-Gm-Message-State: AJaThX6wX35YhMmHcQlJM7lwbeBs05xmJ1JlFtR+xs1DsSgTYmR+jsuA tn2RUOrF4uJDCh4J4a2Vn6J8+1e3FqPnxhxGX7FAqQ==
X-Google-Smtp-Source: AGs4zMYijJimGsW3IryIwi4mNNiqvlDU7bF6PeFTx2Y1DaK/jKg4hJy3xrvlJMwmQGWO7CmKEHF4+cAqygWpFkm/qq4=
X-Received: by with SMTP id o20mr4076473pli.62.1510896428881; Thu, 16 Nov 2017 21:27:08 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 16 Nov 2017 21:27:08 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Bob Harold <>
Date: Fri, 17 Nov 2017 00:27:08 -0500
Message-ID: <>
To: Matthijs Mekking <>
Content-Type: multipart/alternative; boundary="f403045c61acefad63055e26fc5a"
Archived-At: <>
Subject: Re: [DNSOP] 5011-security-considerations and the safetyMargin
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: Fri, 17 Nov 2017 05:27:12 -0000

On Thu, Nov 16, 2017 at 8:33 AM, Matthijs Mekking <>

> Wes,
> My preference is to include safetyMargin and have text to explain it
> exists because of network delays etcetera, and also reference to RFC 5011's
> retryTime. So that's some mix of 1B 1C or 2B I guess :)
> Best regards,
>   Matthijs
> On 15-11-17 02:49, Wes Hardaker wrote:
>> The discussion has been long with respect to the safetyMargin in the
>> 5011 security considerations document.  There hasn't been a huge
>> conclusion and many different ideas have been floated by, and we're now
>> at the point where we need to pick between them.  Below, I try to lay
>> out the primary and sub-options available based on discussions so far.
>> Please provide your opinions on your preference so I can wrap up this
>> draft.
>> Background: This document is not intended to provide operational
>> guidance on what you SHOULD do.  It's intended to draw the timing line
>> below which you MUST NOT venture.  The safetyMargin was introduced to
>> prevent race conditions based on network delays, eg, which can mean that
>> a RFC5011 Resolver operating at the same time as a PEP Publisher making
>> a change at exactly at the minimum addWaitTime or addWallClockTime
>> values would lead to a failure.  So the primary question today is "how
>> do we want to deal with this issue of real-world speed-of-light and
>> other issues?".  To complicate this a bit further, packets are never
>> guaranteed to be delivered and network losses can entirely prevent a
>> 5011 Resolver from succeeding at all for a given operation.
>> Option 1.  Include a safetyMargin of some value.
>>             1A) safetyMargin = MAX(2*TTL, 1.5Hr)   -- current draft
>>             1B) safetyMargin = something based on the retryTime,
>>                 (an example solution was suggested by MSJ)
>>             1C) Your value here
>> Option 2.  Don't include a safetyMargin
>>             2A) Just ignore the issues entirely
>>             2B) Explain that this document does not cover operational
>>                 complexities like retries (already in the -07 version),
>>                 network delays and other operational issues.
>> After thinking about this for far far too long, I've now switched my own
>> opinion to that of 2C for the principal reason that this is the
>> line-in-the-sand document, and to be honest people should be using
>> values much larger than this, per MSJ's guidance on how 5011 should be
>> used.  Thus, it makes more sense to define this as the "MUST NOT go
>> below this line" without trying to be precise about a value that can
>> never be
>> perfectly accurate, by definition.
>> But, forget my opinion.  What's yours?  If nothing else, pick one of the
>> [12][ABC] options above please, even without any text defining why you
>> think so (until someone pokes you).
I prefer 1A since the reasoning is well documented.
or  MAX(1A,1B), but that is more complex for little gain.

Bob Harold