Re: [DNSOP] 5011-security-considerations status

Michael StJohns <> Thu, 01 February 2018 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 978AC12EC96 for <>; Thu, 1 Feb 2018 11:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 y8yt-Y-sXMEQ for <>; Thu, 1 Feb 2018 11:43:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0CE212EC3A for <>; Thu, 1 Feb 2018 11:43:48 -0800 (PST)
Received: by with SMTP id n129so10220880qke.6 for <>; Thu, 01 Feb 2018 11:43:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=F9H4zP7JUurlH9XD//mpj6QwYAZeJxxl0FBbQUtrw7k=; b=IgBcHg4Ip4aEhhJ6zo5RS1zKqvKzwyoe1tmLsWdSRBYRKDHne3k6sXBPqUxq2ndisI 2krGSKvN7KM90EiFhgnoRD/WIJLglEHbqLNZ6Bw0iLQ+BiLp9YWupSo/gcirMY99eyZt zad36/4SKm7Wx0S+yP9SrUoj3JeB4xF0N1u0O/nimYhYqKOrGcPossTjWrWfol1fw8wR UJ3/WsbLJCL3K2910zVqDr2OPG7x6DvlJ6TudgCQyWkdYkx5EViuv/FXaDV9CsclBmeq C2HasNDxsKUEkIBnI78xn1/VPKrNy9hNBWSgyOHcbB+9YTiuaIzAgDzy5uW8PcASw2Y4 YWlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=F9H4zP7JUurlH9XD//mpj6QwYAZeJxxl0FBbQUtrw7k=; b=cNjmEb6odecLexQvaNpJqgmMYSpqDSuJNOmqjvukXbgGAsLJvRTOLRnY3Ph0J8eOO+ 7mfUFQUyrwUt58ytyR70y8+RibOp/fB/LmqlgAUpckVuepQsvWCIePAVPdxmOfVhiTbr Ur1pEqQG4b9MI4He4ZNUKVFELG6NPfsj6MpSFzYiNtxfHy/Vn7ULJUr6KDkjcUdNI3NG Jk1zBVNi3aWAnkpAnWmmJMI6csn4BOBt5q3nhnTNg71l2Fs3pfi8JZ2NjYKIesXf12HG assIc1RQLhY7lpeJvKY4hT7g2JJ/+VC5VAYLh0oSjkAl9SOH7FHBTi+zEA5PvEXFYqUc jOnA==
X-Gm-Message-State: APf1xPB1/rDAO9MmEWBmwwczscU1cjPHBDuhlYbC/UJTIhB567/xO4/l TZFR5+yxOcv8Jvk2l3HAP7YCM+yR
X-Google-Smtp-Source: AH8x226ShtsYYbOnu35BC5OMm5En8l6VrSn4tF1TeJLynPv8AgavU1PVdBWB6afcY27A4JZO9HoYCg==
X-Received: by with SMTP id v24mr3951968qkl.253.1517514227640; Thu, 01 Feb 2018 11:43:47 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id d42sm168672qta.87.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 11:43:46 -0800 (PST)
References: <>
From: Michael StJohns <>
Message-ID: <>
Date: Thu, 1 Feb 2018 14:43:43 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] 5011-security-considerations status
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: Thu, 01 Feb 2018 19:43:52 -0000

*pounds head on table*  I'm really not sure how things get worse each 
time but they appear to.

Please, please get rid of activeRefreshOffset, clockskewDriftMargin and 
retryDriftMargin.    Replace this with a single paragraph noting that 
the maximum time (assuming no retransmissions) a node has to wait after 
its holdDownTime expires is activeRefresh.  (e.g. the conclusion you 
reach at the bottom of 6.1.6).  The rest of the math you have is 
basically explaining why in certain chosen circumstances some nodes 
might get there early.... and that's a don't care when looking at worst 

6.2.1 and its related wall clock calculation should be only

addWaitTime = sigExpirationTime + //  this is the last time that an old 
signature can be replayed
                             activeRefresh + // this is the latest time 
that a node can start its addHoldDown timer (assuming no 
                             addHoldDownTim + // this is the latest time 
that a node can finish its addHoldDown interval (assuming ")
                             activeRefresh + // this is the latest time 
that a node can install the new trust anchor (assuming ")
                             retrySafetyMargin // this is the additional 
time the publisher should wait to compensate for real-world issues 

  I'm done here.  No more responses, no more arguments, no more 
interaction.   Do what you will.  I'll just send out my "-1" and be done 
with it.


On 2/1/2018 1:30 PM, Wes Hardaker wrote:
> Sorry for the long delay to get this version out (vacation, family
> issues, deadlines are all just excuses).
> The -11 version of the document has a redesigned 6.1.6 that I'd love
> everyone to concentrate on.  Hopefully it more clearly articulates the
> issues surrounding Mike's found need to wait yet another activeRefresh
> and spells out the analysis behind the delay better (three potential
> delays, from which we take the maximum value).
> We had spoken at the last meeting of doing another update and a 1 week
> last call again.  Due to the complexity of the changes in -11, I'd like
> to request a 2-week last call instead as I think the changes are
> important enough to warrant a longer LC.  Chairs?  Thoughts?