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

[George Michaelson <[e-mail]>]

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 <[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
>>>
>