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

Tom Pusateri <pusateri@bangj.com> Sun, 26 August 2018 21:42 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 8B801130E40 for <dnsop@ietfa.amsl.com>; Sun, 26 Aug 2018 14:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 v64z17ZLMFTD for <dnsop@ietfa.amsl.com>; Sun, 26 Aug 2018 14:42:54 -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 0F6C9130E2C for <dnsop@ietf.org>; Sun, 26 Aug 2018 14:42:53 -0700 (PDT)
Received: from [172.16.10.126] (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 AA9B22760; Sun, 26 Aug 2018 17:38:30 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <C273A347-C918-428F-9CB9-FBF9426F913A@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E69E446A-993B-4249-8E24-3F0B1F88BA0A"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sun, 26 Aug 2018 17:42:50 -0400
In-Reply-To: <CAPt1N1knPwGFy38c0=xNT_mHwo=vQZmzqNJHc_=Oshcr1OH8sQ@mail.gmail.com>
Cc: dnsop WG <dnsop@ietf.org>
To: Ted Lemon <mellon@fugue.com>
References: <153507165910.12116.7113196606839876181.idtracker@ietfa.amsl.com> <AFB90F6F-5D99-4403-AAB6-1123727973E6@bangj.com> <5B7F5E07.5080100@redbarn.org> <7F91FFF7-71C3-4F8E-82CD-266B170983E0@bangj.com> <C0EE2719-B662-4231-AF51-D3B98B00AD0D@fugue.com> <6D607922-393D-4549-AAFA-49279C260CA4@bangj.com> <3C6100BD-62D6-41ED-B7BF-679F0D4E4113@fugue.com> <5063A32B-4877-4860-BA73-CCB068AB7FCB@bangj.com> <CAPt1N1=tXZNgT6ygAaLFfOMze7hbGZ6q_eN1C3iEo9ryBNcyLg@mail.gmail.com> <98EF2CAC-7C13-4E68-8D2B-EC0659EA9646@bangj.com> <CAPt1N1kFNY4=CUMsTvXmeRREeLAkY8xpBdw4vPDxujgke6QT8A@mail.gmail.com> <963460AA-14BB-44AA-87CA-7F09A707DB5D@bangj.com> <47AE41F8-9F5F-4CC8-B4F0-7E8191011E99@bangj.com> <F4335D3A-0241-437F-A428-8EA95F0A1C18@fugue.com> <56E8B2A6-7B65-4D25-B102-9EFA7E2CBE7B@bangj.com> <86D465A4-F390-4370-83EC-0E72FBE115BE@isc.org> <CAPt1N1=xy+JAtgvvF_+9LiTiefbpTy_Vd0b8gswozA1K1C57Nw@mail.gmail.com> <99FA0B76-D225-45FC-A33C-B65E2673A45E@isc.org> <CAPt1N1kp8Tg5tWEiDCMuMNTmehRsBSkkC1=u+RcvkG6ZCegE-g@mail.gmail.com> <977DF12E-178B-4500-B045-F27BF1CDF51C@isc.org> <CAPt1N1=cafnVmnNM2eSF67QbgRk8hUEAd2Gwuqx4OUehPZSmyQ@mail.gmail.com> <AC3FE6CF-CC11-44D3-8C50-BC19C295F001@bangj.com> <CAPt1N1ksyp1t_e9Qd4FTtTVsZr9+VDm11MR-jS9Oz8Kpz7J7AQ@mail.gmail.com> <9B4A76C4-3BA6-46EC-90EB-E78065FD8BD3@bangj.com> <CAPt1N1=o3KRa_X2KTuW1=KagOv1R0KM=QvT0QBf5YrOSWTr9mw@mail.gmail.com> <461B2749-E2A4-42B8-9FB3-824D96039423@bangj.com> <DEE0C8C8-5557-4D97-B3C8-6535F3EB3693@bangj.com> <CAPt1N1knPwGFy38c0=xNT_mHwo=vQZmzqNJHc_=Oshcr1OH8sQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/o0ruDc8_chZZOPIqOFvQv_TBzH8>
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:42:57 -0000

I actually think the hash won’t be needed as much as you think. If the timeout is the same, even though the record types are different, you still don’t need the hash.

Is this straightforward?

//
//  main.c
//  requires OpenSSL 1.1.1 or later
//
//  Created by Tom Pusateri on 8/26/18.
//  Copyright © 2018 !j.
//
//  MIT LICENSE as specified here: https://opensource.org/licenses/MIT
//

#include <stdio.h>
#include <string.h>
#include <openssl/evp.h>

int main(int argc, const char * argv[]) {
    EVP_MD_CTX *mdctx;
    const EVP_MD *md;
    char msg[] = "This is a test";
    unsigned char md_value[EVP_MAX_MD_SIZE];
    u_int md_len, i;
    
    md = EVP_shake128();
    if (md == NULL) {
        printf("Unknown message digest %s\n", argv[1]);
        exit(1);
    }
    
    mdctx = EVP_MD_CTX_new();
    EVP_DigestInit_ex(mdctx, md, NULL);
    EVP_DigestUpdate(mdctx, msg, strlen(msg));
    EVP_DigestFinal_ex(mdctx, md_value, &md_len);
    EVP_MD_CTX_free(mdctx);
    
    printf("Digest is: ");
    for (i = 0; i < md_len; i++)
        printf("%02x", md_value[i]);
    printf("\n");
    
    exit(0);
}


> On Aug 26, 2018, at 3:42 PM, Ted Lemon <mellon@fugue.com>; wrote:
> 
> You haven't specified how the hash is done, so I can't confirm the truth of your assertion that it's straightforward. :)
> 
> The "only if there are multiple record types" bit doesn't actually help, because I can't actually think of a case where it doesn't apply.   That is, every RR will require a hash, as far as I can tell, in practice.
> 
> 128 bits is 16 bytes—the size of an IPv6 address.   It's probably true that that's shorter than the record in most cases, but I doubt it's enough shorter to make a difference.   And we already know how to compare records—we need that for update.
> 
> On Sun, Aug 26, 2018 at 1:58 PM Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>> wrote:
> 
> 
>> On Aug 26, 2018, at 1:47 PM, Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>> wrote:
>> 
>> 
>> 
>>> On Aug 26, 2018, at 12:58 PM, Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> wrote:
>>> 
>>> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>> wrote:
>>> I think I already agreed with you here.
>>> 
>>> My main point was that the primary needs a database and it already has one and probably doesn’t want another one. Because of the added benefit that Paul points out with promoting a secondary to primary after an extended outage, and the points that Joe makes about treating all records the same, it seems logical to store the lease lifetime information as actual resource records and transfer them to the secondary.
>>> 
>>> FWIW, I think the database storage argument is actually the best argument for this proposal: we need a way to represent  the data structure on disk, and what we know how to store are RRs.
>>> That said, I think that it's worth asking the question of what the right format is, and not just assuming that it's a hash.
>> 
>> 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.
> 
> Also, remember the hash is only needed if there are multiple records types with the same owner name / class having different timeouts (including no timeout).
> 
> So in the case of a unique name being added for a delegated address, the NO HASH value can be used and no hash needs to be calculated. In the case of both an IPv4 and IPv6 address being delegated and subsequently sending an UPDATE with the same owner name, as long as the lease time is the same, again, there is no need for the hash.
> 
> If, however, an RRSIG is dynamically generated for the owner name, then the hash will be needed. (You won’t want to timeout RRSIGs but instead timeout the A/AAAA and then recalculate the RRSIG/NSEC/NSEC3/NSEC5 records.)
> 
> Tom
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop