Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[神明達哉]

At Tue, 3 Apr 2018 21:32:04 +,
"Wessels, Duane"  wrote:

> This draft proposes a technique and new RR type for calculating and
> verifying a message digest over the contents of a zone file.  Using
> this technique, the recipient of a zone containing the new RR type
> can verify it for completeness and correctness, especially so when
> the zone is signed.  We welcome your feedback on this document.

FWIW, I came up with a similar idea and implemented a patch to ISC
BIND 9 as a kind of hobby project.  It's available at:
https://github.com/jinmei/bind9-zonecksum/tree/zonesum
although it doesn't have a way to publish the digest in the form of RR.

And so, obviously, I like the basic idea of the draft:-)

--
JINMEI, Tatuya

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[Shane Kerr]

Wessels, Duane:
> 
>> On Apr 4, 2018, at 4:01 AM, Shane Kerr  wrote:
>>
>> One issue is that the algorithm proposed requires that the recipient who
>> is generating a digest has to store basically the entire zone before
>> beginning the digest calculation, since it has no way to know if the
>> zone will be delivered in any kind of canonical order.
> 
> Yes.  Certainly for large zones this could be an issue.  We will have to
> find the right balance between complexity and efficiency here.
> 
> I think it makes the most sense to perform a verification when the zone is
> loaded or received by a name server, but it could also be done in an external
> process, such as named-checkzone or ldns-verify-zone.
> 
> 
>>
>> As for specific questions in the draft:
>>
>> * I think that it should be allowed for unsigned zones. If nothing else,
>>  it provides the equivalent of checksum to help prevent truncations or
>>  not properly updated records (missing deletions or additions).
>>
>> * I don't see much benefit in multiple ZONEMD. We generally expect
>>  masters & slaves to co-operate, so they should be able to find
>>  software that has an algorithm that both sides support.
> 
> Yes, but master/slave transfers can already be protected with TSIG.  Perhaps
> the more interesting use case is out-of-band zone distribution.

I have seen zones get broken by transfer in production. I'd say it is
useful any time you transfer zones.

I think an interesting use case is detecting intentional modification by
the master (or a case where the master master is compromised in any way).

If you're just trying to verify the integrity of a file during transfer,
then yes TSIG is sufficient, but then so is a simple sha256sum on a file
that you copy out-of-band.

>> * I think the serial in ZONEMD is helpful. Doesn't it also help prevent
>>  replay attacks?
> 
> You might have to convince me that it does...

Actually you're right. Since the SOA is included in the digest, the
serial in the ZONEMD is not necessary. Probably it should be removed.

>> * I would rather not special-case ZONEMD regarding responding. Even
>>  though it is bigger than most RDATA, large responses seem like a
>>  general problem. OTOH, I won't object too loudly if someone feels very
>>  strongly that this should be an option.
>>
>> A final possible concern is that generating a digest on a large zone
>> might be computationally quite expensive. Indeed it could be used as an
>> attack vector on a hosting provider by using small IXFR to cause large
>> zone digests to be repeatedly calculated. Is it worth exploring the
>> possibility of including multiple ZONEMD in a zone at different names,
>> which digest the part of the zone up to that point? So something like:
> 
> 
> Yes, as currently specified it probably only works well with relatively 
> static zones.
> Again, we'll have to decide where we want to be in the complexity vs 
> efficiency tradeoff.

I don't think that the complexity of having ZONEMD that covers part of a
zone is very high. Certainly from either a master or a slave basically
you just need to reinitialize your hash context and continue rolling
along, right?

Probably given our new camel-busting revolution I should implement the
draft before I make any such claims though...

Cheers,

--
Shane

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[Wessels, Duane]

> On Apr 4, 2018, at 6:15 AM, Tony Finch  wrote:
> 
> A couple of thoughts/questions:
> 
> The sorting algorithm specifies CLASS as part of the sort key. This is
> fine, but slightly redundant since all records in a zone have the same
> class :-)

Okay.  I managed to convince myself that zone files could contain multiple
classes, but looking now I see in 1035 it says "All RRs in the file should
have the same class."


> 
> Regarding efficiency, I wonder if there would be much win from giving it a
> bit more of a tree structure, e.g.
> 
> ; similar ordering to RRSIG calculation
> digest_RRset(n,r) = digest_algorithm( RRsig(i,1) | ... | RRsig(i,si) |
>  RR(i,1) | ... | RR(i,ri) )
> 
> digest_owner(n) = digest_algorithm( digest_RRset(n,1) | ... )
> 
> digest = digest_algorithm( digest_owner(1) | ... )
> 
> So when updating a zone, you can just recalculate the digests for the
> affected owner names, then re-digest the string of digests. This should be
> faster for signed zones, but it might not be a win for unsigned zones (a
> SHA256 is about the same size as an A record).
> 
> (Following the hierarcial structure of owner names is probably not worth
> it given the flatness of most zones.)
> 
>> Is it worth exploring the possibility of including multiple ZONEMD in a
>> zone at different names, which digest the part of the zone up to that
>> point?
> 
> Also a good idea :-) It probably needs to look a bit more like NSEC to
> make it explicit which owners are covered.

My initial reaction is that I'm not fond of the complexity, but would like
to hear if people think zone digest is useful for the types of zones where
recalculation is a significant concern.

DW

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[Wessels, Duane]

> On Apr 4, 2018, at 4:01 AM, Shane Kerr  wrote:
> 
> One issue is that the algorithm proposed requires that the recipient who
> is generating a digest has to store basically the entire zone before
> beginning the digest calculation, since it has no way to know if the
> zone will be delivered in any kind of canonical order.

Yes.  Certainly for large zones this could be an issue.  We will have to
find the right balance between complexity and efficiency here.

I think it makes the most sense to perform a verification when the zone is
loaded or received by a name server, but it could also be done in an external
process, such as named-checkzone or ldns-verify-zone.


> 
> As for specific questions in the draft:
> 
> * I think that it should be allowed for unsigned zones. If nothing else,
>  it provides the equivalent of checksum to help prevent truncations or
>  not properly updated records (missing deletions or additions).
> 
> * I don't see much benefit in multiple ZONEMD. We generally expect
>  masters & slaves to co-operate, so they should be able to find
>  software that has an algorithm that both sides support.

Yes, but master/slave transfers can already be protected with TSIG.  Perhaps
the more interesting use case is out-of-band zone distribution.

> 
> * I think the serial in ZONEMD is helpful. Doesn't it also help prevent
>  replay attacks?

You might have to convince me that it does...

> 
> * I would rather not special-case ZONEMD regarding responding. Even
>  though it is bigger than most RDATA, large responses seem like a
>  general problem. OTOH, I won't object too loudly if someone feels very
>  strongly that this should be an option.
> 
> A final possible concern is that generating a digest on a large zone
> might be computationally quite expensive. Indeed it could be used as an
> attack vector on a hosting provider by using small IXFR to cause large
> zone digests to be repeatedly calculated. Is it worth exploring the
> possibility of including multiple ZONEMD in a zone at different names,
> which digest the part of the zone up to that point? So something like:


Yes, as currently specified it probably only works well with relatively static 
zones.
Again, we'll have to decide where we want to be in the complexity vs efficiency 
tradeoff.

DW

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[Tony Finch]

Shane Kerr  wrote:
> Wessels, Duane:
> >
> > This draft proposes a technique and new RR type for calculating and
> > verifying a message digest over the contents of a zone file.  Using
> > this technique, the recipient of a zone containing the new RR type can
> > verify it for completeness and correctness, especially so when the
> > zone is signed.  We welcome your feedback on this document.
>
> I think this is a great idea. Certainly one of the things that we were
> missing in the Yeti project was a way to confirm that the contents of
> the root zone transfered from any particular master were actually the
> correct version, so this fills a real need.

Yep, interesting.

A couple of thoughts/questions:

The sorting algorithm specifies CLASS as part of the sort key. This is
fine, but slightly redundant since all records in a zone have the same
class :-)

Regarding efficiency, I wonder if there would be much win from giving it a
bit more of a tree structure, e.g.

; similar ordering to RRSIG calculation
digest_RRset(n,r) = digest_algorithm( RRsig(i,1) | ... | RRsig(i,si) |
  RR(i,1) | ... | RR(i,ri) )

digest_owner(n) = digest_algorithm( digest_RRset(n,1) | ... )

digest = digest_algorithm( digest_owner(1) | ... )

So when updating a zone, you can just recalculate the digests for the
affected owner names, then re-digest the string of digests. This should be
faster for signed zones, but it might not be a win for unsigned zones (a
SHA256 is about the same size as an A record).

(Following the hierarcial structure of owner names is probably not worth
it given the flatness of most zones.)

> Is it worth exploring the possibility of including multiple ZONEMD in a
> zone at different names, which digest the part of the zone up to that
> point?

Also a good idea :-) It probably needs to look a bit more like NSEC to
make it explicit which owners are covered.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Plymouth, Biscay: West 5 to 7, occasionally gale 8 at first, backing south 3
or 4, occasionally 5 later. Rough or very rough. Showers, then fair. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[Shane Kerr]

Duane,

Wessels, Duane:
> 
> This draft proposes a technique and new RR type for calculating and verifying 
> a message digest over the contents of a zone file.  Using this technique, the 
> recipient of a zone containing the new RR type can verify it for completeness 
> and correctness, especially so when the zone is signed.  We welcome your 
> feedback on this document.

I think this is a great idea. Certainly one of the things that we were
missing in the Yeti project was a way to confirm that the contents of
the root zone transfered from any particular master were actually the
correct version, so this fills a real need.

One issue is that the algorithm proposed requires that the recipient who
is generating a digest has to store basically the entire zone before
beginning the digest calculation, since it has no way to know if the
zone will be delivered in any kind of canonical order. It might be nice
to have some way to signal that. I'm not sure exactly how, and possibly
that belongs in a separate document (maybe we can tack it onto MIXFR?),
but it seems like a potential problem as it adds extra work (possibly
re-reading the entire zone an extra time along with the associated I/O,
memory consumption, and unneeded latency due to checking).

As for specific questions in the draft:

* I think that it should be allowed for unsigned zones. If nothing else,
  it provides the equivalent of checksum to help prevent truncations or
  not properly updated records (missing deletions or additions).

* I don't see much benefit in multiple ZONEMD. We generally expect
  masters & slaves to co-operate, so they should be able to find
  software that has an algorithm that both sides support.

* I think the serial in ZONEMD is helpful. Doesn't it also help prevent
  replay attacks?

* I would rather not special-case ZONEMD regarding responding. Even
  though it is bigger than most RDATA, large responses seem like a
  general problem. OTOH, I won't object too loudly if someone feels very
  strongly that this should be an option.

A final possible concern is that generating a digest on a large zone
might be computationally quite expensive. Indeed it could be used as an
attack vector on a hosting provider by using small IXFR to cause large
zone digests to be repeatedly calculated. Is it worth exploring the
possibility of including multiple ZONEMD in a zone at different names,
which digest the part of the zone up to that point? So something like:

a.example.com ...
 .
 .
 .
n.example.com ...
n.example.com ... ZONEMD ...  ; covers a-n
 .
 .
 .
z.example.com ...
example.com ... ZONEMD ... ; covers o-z

(Sorry this needs to be more carefully thought through, but that's the
basic idea.)

Cheers,

--
Shane

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop