Re: [DNSOP] [Ext] Reserved field in draft-wessels-dns-zone-digest-04.txt
> On Nov 3, 2018, at 1:33 PM, Wes Hardaker wrote:
>
> Paul Hoffman writes:
>
>> From the earlier list discussion and your presentation at DNS-OARC,
>> processing dynamic zones is hard, and you might make different choices
>> based on different amounts of dynamicness (dynamicity?). This should
>> cause developers concern about implementing ZONEMD now because there
>> will be an expectation that they will have to implement the changes in
>> the future.
>
> I also look at it in terms of implementation complexity and where in the
> code base decisions are made. EG, if you have different RRTYPEs for
> signaling things, then the logic is straight forward:
>
>if (rrtype == ZONEMD) {
> do_ZONEMD_stuff();
>} else if (rrtype == ZONEMDMERKLE) {
> do_fancy_new_hashtree_stuff();
>} ...
>
> On the other hand, with a reserved field we end up here:
>
>if (rrtype == ZONEMD) {
> do_ZONEMD_stuff();
>} ...
>
>
>do_ZONEMD_stuff() {
>if (reserved_field != 0) {
>do_fancy_new_hashtree_stuff();
>} else {
>do_ZONEMD_stuff();
>}
>}
>
> Now, if do_ZONEMD_stuff() and do_fancy_new_hashtree_stuff() are likely
> to be sufficiently different in implementation (and I suspect they will
> be), then the first code above with two RRTYPEs is likely to be
> cleaner. The only advantage gained in the second type is if you can put
> the brunt of the code for both do_fancy_new_hashtree_stuff() and
> do_ZONEMD_stuff() pretty much inline because there is sufficient
> overlap.
>
> It's hard to predict what the best route is advance without knowing now
> how much the resulting double implementation will overlap.
So there is an implementation of ZONEMD, and even an implementation of "fancy
hashtree stuff". You can find it at
https://github.com/verisign/ldns-zone-digest
One of the reasons I think the variable-depth hash tree is attractive is
because when depth = 0 then it simplifies exactly to the case as though there
is no fancy hashtree.
In my proof-of-concept implementation, most of the added complexity from fancy
hashtree stuff comes in the form of how the zone data is stored. For example:
#if !ZONEMD_INCREMENTAL
ldns_rr_list *the_rrlist = 0;
#endif
#if ZONEMD_INCREMENTAL
typedef struct _zonemd_tree {
unsigned int depth;
unsigned int branch;// only for debugging?
ldns_rr_list *rrlist;
struct _zonemd_tree *parent;
struct _zonemd_tree **kids;
unsigned char digest[EVP_MAX_MD_SIZE];
bool dirty;
} zonemd_tree;
#endif
But the actual digest calculation is not that much more complex for fancy
hashtree sutff, IMO. The only difference is what you feed as input to the hash
function. At the non-leaf nodes the input is hash values of the child nodes.
At the leaf nodes the input is the RRs wire format data.
DW
smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Reserved field in draft-wessels-dns-zone-digest-04.txt
Paul Hoffman writes:
> From the earlier list discussion and your presentation at DNS-OARC,
> processing dynamic zones is hard, and you might make different choices
> based on different amounts of dynamicness (dynamicity?). This should
> cause developers concern about implementing ZONEMD now because there
> will be an expectation that they will have to implement the changes in
> the future.
I also look at it in terms of implementation complexity and where in the
code base decisions are made. EG, if you have different RRTYPEs for
signaling things, then the logic is straight forward:
if (rrtype == ZONEMD) {
do_ZONEMD_stuff();
} else if (rrtype == ZONEMDMERKLE) {
do_fancy_new_hashtree_stuff();
} ...
On the other hand, with a reserved field we end up here:
if (rrtype == ZONEMD) {
do_ZONEMD_stuff();
} ...
do_ZONEMD_stuff() {
if (reserved_field != 0) {
do_fancy_new_hashtree_stuff();
} else {
do_ZONEMD_stuff();
}
}
Now, if do_ZONEMD_stuff() and do_fancy_new_hashtree_stuff() are likely
to be sufficiently different in implementation (and I suspect they will
be), then the first code above with two RRTYPEs is likely to be
cleaner. The only advantage gained in the second type is if you can put
the brunt of the code for both do_fancy_new_hashtree_stuff() and
do_ZONEMD_stuff() pretty much inline because there is sufficient
overlap.
It's hard to predict what the best route is advance without knowing now
how much the resulting double implementation will overlap.
Personally (authorship hat off and thus collector of consensus hat off),
I think we should use a second RRTYPE for the future as it's easier to
make implementations more module and remove earlier implementations when
that specification is no longer used because hashtrees are so cool that
nothing else is ever needed.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Reserved field in draft-wessels-dns-zone-digest-04.txt
On Oct 24, 2018, at 2:57 AM, Wessels, Duane wrote: > > > >> On Oct 24, 2018, at 12:16 AM, Paul Hoffman wrote: >> >> Section 5 says: >> >> FOR DISCUSSION: The authors are willing to remove the Reserved field >> from this specification if the working group would prefer it. It >> would mean, however, that a future version of this protocol designed >> to efficiently support large, dynamic zones would most likely require >> a new RR type. >> >> Please strongly consider removing the Reserved field so that designing an >> way to do a message digest over a dynamic zone can be done independently. >> >> Quite frankly, if the Reserved field isn't there and it's clear that this is >> for complete zones, I see no reason why this should even be considered >> experimental. The mic line at the presentation at the recent DNS-OARC seems >> to agree with wanting this for real, as soon as possible. > > > Thanks for the feedback, Paul. > > Personally I feel like keeping the Reserved field is potentially useful in > the future, but harmless if it never gets used. Can you say more about why > keeping it prevents independent work? From the earlier list discussion and your presentation at DNS-OARC, processing dynamic zones is hard, and you might make different choices based on different amounts of dynamicness (dynamicity?). This should cause developers concern about implementing ZONEMD now because there will be an expectation that they will have to implement the changes in the future. On the other hand, if you indicate "ZONEMD is for the static zones, and there will be a different RRtype for dynamic zones", vendors can choose later whether to implement the new RRtype. As others have said, new RRtypes are cheap. > I would be very happy with standards track, but to the extent the WG is > skeptical I would settle for experimental at this time. I am not skeptical of the current protocol: I am skeptical of unknown changes to it in the future. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
