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

[George Michaelson <[e-mail]>]

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 <[e-mail]> wrote:
>
>
>> On 10 Jul 2018, at 10:22 am, George Michaelson <[e-mail]> 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 <[e-mail]> wrote:
>>> George,
>>>
>>>
>>>> On Jul 9, 2018, at 4:36 PM, George Michaelson <[e-mail]> 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 <[e-mail]> wrote:
>>>>>
>>>>>> On Jul 8, 2018, at 6:02 PM, George Michaelson <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]              INTERNET: [e-mail]
>