[DNSOP] 5011-security-considerations and the safetyMargin

Wes Hardaker <wjhns1@hardakers.net> Wed, 15 November 2017 01:51 UTC

Return-Path: <wjhns1@hardakers.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 31A13128AFE for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 17:51:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ANNbYuPcaglK for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 17:51:55 -0800 (PST)
Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A49D1200CF for <dnsop@ietf.org>; Tue, 14 Nov 2017 17:51:55 -0800 (PST)
Received: from localhost (dhcp-8309.meeting.ietf.org []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 1AA382808D for <dnsop@ietf.org>; Tue, 14 Nov 2017 17:51:53 -0800 (PST)
From: Wes Hardaker <wjhns1@hardakers.net>
To: dnsop@ietf.org
Date: Tue, 14 Nov 2017 17:49:35 -0800
Message-ID: <ybld14kpaz4.fsf@wu.hardakers.net>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/otFC67hr4CUox8BkFkwFD6TU9TQ>
Subject: [DNSOP] 5011-security-considerations and the safetyMargin
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 01:51:56 -0000

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

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

Wes Hardaker