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

[Shumon Huque <[e-mail]>]

On Tue, Jun 19, 2018 at 2:56 PM Wessels, Duane <[e-mail]>
wrote:

>
> > On Jun 19, 2018, at 11:11 AM, Shumon Huque <[e-mail]> wrote:
> >
> >
> > On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček <[e-mail]> wrote:
> >
> > I think we need to first answer question why existing technologies do
> > not fit the purpose.
> >
> > This is a reasonable question.
> >
> > I noticed that the draft doesn't mention SIG(0) at all.
>
> I suppose this is happened because, as you say it isn't widely implemented
> or used.
>
> > One of the main motivators of the draft is stated to be secure, wide
> scale distribution of the root zone. To me, SIG(0) would have been an
> obvious candidate solution for this problem. The zone owner can publish one
> public key to the world,
>
> My reading of RFC 2931 contradicts this.  For example:
>
> 2.3 Keying
>
>    The private keys used in transaction security belong to the host
>    composing the DNS response message, not to the zone involved.
>
> In other words, SIG(0), like TSIG, is about asserting the security of an
> individual transaction from a particular server, not the contents of zone
> data.
>

Ah, right - I had forgotten that little detail - thanks for reminding me :)

I guess that was the design goal then, although it didn't have to be that
way. So, with SIG(0) as currently defined, we need a SIG(0) key per
authoritative server name ..


> >
> > Possible issues with SIG(0):
> >
> > * Although it is an existing technology, it isn't widely implemented or
> used. I just learned on DNS twitter that BIND only supports SIG(0) for
> UPDATE for example, and not XFR.
> >
> > * If the goal is to support secure acquisition of the zone outside the
> DNS protocol, then it can't do that. But neither is ZONEMD needed for that
> - we can use an out of band signature using a variety of methods.
>
> Yes, this is the crux of it for me and the other authors as well I
> believe.  In my opinion, detached signatures/checksums are not good
> enough.  Our not-yet-released -02 draft has this new text:
>
> 1.1.2.  Detached Signatures
>
>    Sometimes, detached checksums and signatures can be found adjacent to
>    zone files.  This is the case for the root and other zone files
>    published on the internic.net sites [InterNIC].  For example, the
>    files root.zone.md5 and root.zone.sig are in the same directory as
>    the root.zone file.  Unfortunately, since the checksum and signature
>    are in separate files, they are only weakly associated with the zone
>    file.  They remain associated only if the recipient is careful to
>    keep them together.  Nothing in these files, other than their names
>    and timestamps, ties them to a specific revision of the root.zone
>    file.
>

Yes, that's a reasonable argument ..

Shumon.