> On Jun 19, 2018, at 11:11 AM, Shumon Huque <shu...@gmail.com> wrote: > > > On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček <petr.spa...@nic.cz> 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. Also: The corresponding public key(s) are normally stored in and retrieved from the DNS for verification as KEY RRs ... Thus it will be necessary to keep the private key on-line, for example in software or in a directly connected piece of hardware. It doesn't make sense to me to consider using KEY RRs and online private keys when we already have working DNSSEC infrastructure. > and signs zone transfers messages with the corresponding secret key. If the > zone owner supports IXFR, the incremental cost of these message signatures is > also quite small. > > 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. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
