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

[Ted Lemon <[e-mail]>]

The timeout *isn't* the same for DNSSD Registration Protocol.

On Sun, Aug 26, 2018 at 5:42 PM Tom Pusateri <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]> wrote:
>
>>
>>
>> On Aug 26, 2018, at 1:47 PM, Tom Pusateri <[e-mail]> wrote:
>>
>>
>>
>> On Aug 26, 2018, at 12:58 PM, Ted Lemon <[e-mail]> wrote:
>>
>> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>