Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

Tom Pusateri <pusateri@bangj.com> Sun, 26 August 2018 21:53 UTC

Return-Path: <pusateri@bangj.com>
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 992E7130E2C for <dnsop@ietfa.amsl.com>; Sun, 26 Aug 2018 14:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 OYczSC_zZp5a for <dnsop@ietfa.amsl.com>; Sun, 26 Aug 2018 14:53:22 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4DB130E03 for <dnsop@ietf.org>; Sun, 26 Aug 2018 14:53:22 -0700 (PDT)
Received: from [172.16.10.128] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 4F522276C; Sun, 26 Aug 2018 17:48:59 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Tom Pusateri <pusateri@bangj.com>
X-Mailer: iPhone Mail (16A5364a)
In-Reply-To: <2581322.trI6Ix2n6k@linux-9daj>
Date: Sun, 26 Aug 2018 17:53:20 -0400
Cc: dnsop@ietf.org, Ted Lemon <mellon@fugue.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AA14BDA5-2173-4CED-97E7-3F550ADCB51C@bangj.com>
References: <153507165910.12116.7113196606839876181.idtracker@ietfa.amsl.com> <CAPt1N1=o3KRa_X2KTuW1=KagOv1R0KM=QvT0QBf5YrOSWTr9mw@mail.gmail.com> <461B2749-E2A4-42B8-9FB3-824D96039423@bangj.com> <2581322.trI6Ix2n6k@linux-9daj>
To: Paul Vixie <vixie@fsi.io>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PktTwBHVoV-56zUETkqNA_9_lWk>
Subject: Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Sun, 26 Aug 2018 21:53:24 -0000


> On Aug 26, 2018, at 3:59 PM, Paul Vixie <vixie@fsi.io>; wrote:
> 
>> On Sunday, August 26, 2018 5:47:43 PM UTC Tom Pusateri wrote:
>> ...
>> Nice properties of the hash:
>> 
>> 1. the length of the output value is consistent across varying input lengths
>> of any RR type (128 bits in the case of the algorithm specified in the
>> draft) making it easy to sequence through. 2. it’s independently verifiable
>> between servers and across time on the same server 3. it’s independent of
>> position of the RR it covers 
>> 4. it works the same for all existing RR’s as well as RR’s yet to be defined
>> 
>> Other methods may share some of these properties but I’m just listing all of
>> the ones I can think of.
> 
> as i wrote about a hash that was proposed in part of zone catalog work, there 
> are two things that are really bad about these. 
> 
> 1. the resulting design is not collision-resilient
> 
> 2. the hash will have to change some day, invoking rollover complexity cost
> 
> while DHT is a better example of "use a hash because it's magic and makes it 
> look like our coherency problems have gone away", in fact all non-security-
> related hash uses should be suspected of the same. you won't want to use a 
> hash in a distributed system (where hash values have to be portable) unless 
> every alternative has a vastly higher cost.
> 
> -- 
> Vixie

SHAKE128 as well as other SHA-3 algorithms have been found to be quite collision resistant.

Tom