What I want is the nexus of OOB "file" form zone download and integrity check which is cheap to implement signer and receiver.
I was on PGP. Duane has taken me to an RR which is a sequenced, canonicalized digest, which then is under the ZSK sign of the zone. For the root, it feels doable. For Com, nothing but a cipher-block-chain model of intermediates is going to scale but a single file download and integrity check was always going to fail there. I know you're talking in-band download: I am targetting out of band "file" download. Its a model. It works. Its useful. The least dependencies and easiest path is what I seek, Olafur drove to a new keying regime and external signatures. Duane has taken me back to "you can use what you have, if you will canonicalize the file to make the RR for a digest" -G On Tue, Jul 10, 2018 at 12:01 PM, Mark Andrews <[email protected]> wrote: > > >> On 10 Jul 2018, at 10:22 am, George Michaelson <[email protected]> wrote: >> >> 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 > > The problem with what is currently there is that it requires the *entire* > zone to walked on every dynamic update to recompute the hash. That has > always been the primary objection to SIG(AXFR). > > We can do the hashing (and signing) on much smaller increments. > > We could sign each RRset that is not already signed (GSIG) in the zone and > introduce a glue NSEC like record (GSEC) to prevent those RRsets being > removed. > > We could hash larger collections of RRsets but smaller than a the whole zone. > That is what XSIG that I proposed earlier does. It hashes the currently > unsigned zone data and prevents its removal from the zone. I don’t care if > it is XSIG or XHASH which is then signed. Mathematically they are the same. > This mechanism works with OPTOUT and NSEC3 as well as NSEC but does require > the unsigned delegations to be hashed if enabled. > > Mark > > > >> On Tue, Jul 10, 2018 at 10:05 AM, Wessels, Duane <[email protected]> >> wrote: >>> George, >>> >>> >>>> On Jul 9, 2018, at 4:36 PM, George Michaelson <[email protected]> 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 <[email protected]> >>>> wrote: >>>>> >>>>>> On Jul 8, 2018, at 6:02 PM, George Michaelson <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
