Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

Petr Špaček <petr.spacek@nic.cz> Fri, 17 February 2017 12:00 UTC

Return-Path: <petr.spacek@nic.cz>
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 103391299BE for <dnsop@ietfa.amsl.com>; Fri, 17 Feb 2017 04:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 qPnTpjkaEH-P for <dnsop@ietfa.amsl.com>; Fri, 17 Feb 2017 04:00:02 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA201299C4 for <dnsop@ietf.org>; Fri, 17 Feb 2017 04:00:01 -0800 (PST)
Received: from [IPv6:2001:1488:fffe:6:6838:2cff:fe1a:3e51] (unknown [IPv6:2001:1488:fffe:6:6838:2cff:fe1a:3e51]) by mail.nic.cz (Postfix) with ESMTPSA id 07E966010D; Fri, 17 Feb 2017 12:59:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487332799; bh=/c4rN0qkgaRFaDRXFbZQqDCGTuIGDd9cixCqzqjabMc=; h=To:From:Date; b=v1ft8PKnPqqQz5cQyG7ghkzx5zcrr6biSy54hF7JlR1wM+zHbsa3BV7D6i2Sq4n7b SIijQWCaIADhMbYTCy7hefw50MtEMX2/yTeMeZDrob0FyWDM79ANIkFkmsB57bX15V v0LBMUombBB5IyhK50awK1V5MGXxS+b68PS95pes=
To: dnsop@ietf.org, Wes Hardaker <wjhns1@hardakers.net>
References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> <CAHw9_iKYkZNG=JLSUbCVpsrmkupFM6635eMHJsQXDWcLJmLgKQ@mail.gmail.com> <20170206131153.52329a04@pallas.home.time-travellers.org> <7dd02b3e-910b-b287-14cf-d7fe7755cd2d@nic.cz> <ybla89mcdcg.fsf@w7.hardakers.net> <yblwpcqavtg.fsf@w7.hardakers.net> <yblo9y1bu30.fsf@w7.hardakers.net>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <8f3db72f-69ff-be02-2e30-2499f77dd2cb@nic.cz>
Date: Fri, 17 Feb 2017 12:59:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <yblo9y1bu30.fsf@w7.hardakers.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PcjTq_lkvxUzt9dvTWHH0eSr9Mw>
Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 17 Feb 2017 12:00:04 -0000

On 02/17/2017 12:21 AM, Wes Hardaker wrote:
> Wes Hardaker <wjhns1@hardakers.net> writes:
> 
>> Fortunately, after a quick conversation we've recovered the reason.
>> Publishing a new version with a break-out explanation shortly.  The 3/2
>> is absolutely is needed.
> 
> I've published -03 which adds new text just below the equation
> explaining the components (and the equation got more complex to match
> the complexity of 5011).

Thanks! The equation seems more complex at first glance but it is way
more understandable for me.

When reading the quote from the RFC5011 "Active Refresh" requirements, I
realized the equation is not complete without:
  MAX(MIN(...), 1 hour)

I.e. the waitTime would be too short for quick turn-around zones. This
is probably not that important for practical deployment but it gets
veeery important when transforming RFC text to a compliance test.

Please add the MAX(), it will help someone in future. (I'm just trying
to write compliance test for RFC 6672 ...)


> Anyway, please do let me know if you think the new text adequately
> explains the problem to you.
The explanation seems good to me. Just a few comments about the text:

It would be easier to understand for me if this paragraph was split into
two (1st the constraint + 2nd prelude for analysis):
/the matter/
  The important timing constraint that must be considered is the last
  point at which a validating resolver may have received a replayed the
  original DNSKEY set (K_old) without the new key.  It's the next query
  of the RFC5011 validator that the assured K_new will be seen.

/prelude for analysis/
  For
  the following paragraph, we use the more common case where (DNSKEY
  RRSIG Signature Validity) is greater than (original TTL for the
  DNSKEY RRSet), although the equation above takes both cases into
  account.


Moreover the /prelude for analysis/ seems little bit confusing. What
about something along these lines?

/replacement prelude for analysis, preferably as separate paragraph/
  The interval used by RFC5011 resolver is determined by lesser of
  (DNSKEY RRSIG Signature Validity) or (original TTL for the DNSKEY
  RRSet). Following text assumes that (DNSKEY RRSIG Signature Validity)
  is smaller of the two.

/original text continues here/
  Thus, ...


> I probably need to go back and insert the
> "worst case" timing into the example timeline, but that would make the
> example a bit more messy.

It seems sufficient to me to keep the analysis in (current) section 6.
Maybe just a forwad-reference would suffice.

Thank you for the clarification!

-- 
Petr Špaček  @  CZ.NIC