Yea, having read things properly and been hit by a cluestick I think this is good.
* the RR is a digest over canonicalized state * there is a simple method to take zone, re-canonicalize (its the DNSSEC order) and check the digest * since the RR is covered by the ZSK signing, the entire zone is understood to be in the state the publisher had when they made the digest. * if you download a zone file, with this RR, you can re-canonicalize and check easily. You have to have a DNSSEC ta over the keys used come what may, but this looks like a mechanism which given an out of band TA has no in-band DNS dependency to get a zone and check a zone. So functionally, Duanes thing is identical in outcome to PGP signing or other exterior file signatures. -G On Tue, Jul 10, 2018 at 10:05 AM, Wessels, Duane <dwess...@verisign.com> wrote: > George, > > >> On Jul 9, 2018, at 4:36 PM, George Michaelson <g...@algebras.org> wrote: >> >> There's arguments both sides about cross signing, counter signing and >> independent self-signing. If you want to promote out of band zone >> exchange, it has to be signed. The key it signs with is immaterial if >> you either direct knowledge of the PK in a PKI, or accept a trust >> anchor relationship over it, or a web of trust. > > I'm not here to promote out-of-band distribution, but I think its going > to happen (especially for the root zone) and I want something that works > just as well for in- and out-of-band distribution. > > I think it makes sense that name server software, whether recursive or > authoritative, can use a technique like this to verify zone data, whether > it is loaded from disk or received over the network. > > The key may be immaterial, but I think the barrier to implementation is > much lower if it can be done with what we already have (DNSSEC) rather than > having to drag something like PGP in. > > > >> So do you prefer (for instance) that the ZSK be used outside of DNSSEC >> to sign a detached signature over the file, irrespective or content >> order, if the file is to be made available? > > Sorry I don't quite follow. What we're suggesting is not a signature over > the file/data, but a hash over the data, which in turn can be signed. > >> Because if you basically >> prefer its *not signed* for this mode of transfer, you've stepped > > For me the mode of transfer is irrelevant. My goal is to secure the data, > not the transfer. > >> outside the model: you now demand the file is checked on load, element >> by element, against the TA, rather than being integrity checked by a >> MAC signed by the issuer, which permits eg direct binary loadable, or >> other states. > > We're not demanding anything (MAY/SHOULD vs MUST) but what we propose is, as > you say, MAC signed by the issuer. > > DW > > >> >> -G >> >> On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane <dwess...@verisign.com> >> wrote: >>> >>>> On Jul 8, 2018, at 6:02 PM, George Michaelson <g...@algebras.org> wrote: >>>> >>>> So how about use of a PGP key which is a payload in TXT signed over by >>>> the ZSK/KSK so the trust paths bind together? >>>> >>>> fetch one DNS record +sigs, check against the TA (which has to be a >>>> given) and then.. >>> >>> Currently in the zone digest draft DNSSEC is not mandatory. That is, the >>> zone >>> needn't necessarily be signed and a receiver need not perform the >>> validation if >>> they don't want to. >>> >>> Even without DNSSEC the digest gives you a little protection from >>> accidental corruption. But not from malicious interference of course. >>> >>> It seems kind of silly to me to double up on public key cryptosystems. We >>> already have keys attached to zones and software that generates and >>> validates signatures. >>> >>> DW >>> > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
