Re: [DNSOP] Comments on draft-wessels-dns-zone-digest-02 (fwd)

I am not objecting other then having 0 desire to help out unsigned zones replace origin security with transport security.

Look at the suggested use of eSNI in unsigned DNS assuming some kind of DOH / DOT transport.

This record type could easily be abused for that.

Which is why my preference is to only sign unsigned records.

Certainly, for the root zone, RRSIGs can be validated. For other large zones where that is not the case there isn’t really a use case either. Those large TLDs can’t be distributed as a file without being obsolete once the transfer completed.

Paul

Sent from my phone

> On Aug 10, 2018, at 17:22, Joe Abley <jabley@hopcount.ca> wrote:
>
> Paul, you seem suspicious that there is some underhand camel attack
> being planned, here, and that the forces of good must assemble to
> reveal the ugly truth and save the caravan.
>
> I think being able to verify the integrity of a zone as a complete
> data structure is useful.
>
> I think interop is useful.
>
> I think this specification is pretty good.
>
> I think stable specifications promote interop and make things like
> this more useful.
>
> Your objections seem to boil down to: I don't like this; I'd achieve
> the kinds of things you want to achieve in other ways. That seems like
> useful input to a document that discusses the relative merits of doing
> things in many ways; that's not what this document is about, though.
>
> So I must be missing something because I don't understand what you're
> objecting to.
>
>> On Aug 10, 2018, at 16:41, Paul Wouters <paul@nohats.ca> wrote:
>>
>> On Fri, 10 Aug 2018, Wessels, Duane wrote:
>>
>>>> But there are already mechanisms for this at the data set level.  (This is a "belts and suspenders" style argument.)  What if -err- when, in a zone's distribution, the glue records are either forged or simply fat-fingered?  That's covered, in a way that is more efficient - in a lazy evaluation way.  Mangled glue never referenced needs not be checked, when it is needed there's backup in the authoritative version.  If all else fails, DNSSEC will flag whatever response as suspect.
>>>
>>> Yes, certainly DNSSEC protects from modification of answers.  It generally protects recursives who validate.  But it doesn't protect consumers of zone files.
>>
>> By design....
>>
>>> Another limitation I've mentioned before, where DNSSEC doesn't protect you, is that a delegation could be falsified such that traffic goes to an eavesdropper that just records but doesn't modify messages.
>>
>> but on most networks you connect to that you don't trust, they could
>> just be monitoring all your port 53 traffic anyway? I don't see this
>> much as a use case. An attacker that cannot see your traffic, but could
>> get to see your DNS root queries but only briefly if you cache or
>> actually use the root zone you just transfered from them. Also query
>> minimalization makes that use case very uninteresting.
>>
>>> I'd also argue that maybe applications shouldn't necessarily trust a file just because its "on disk." The application doesn't know how it got there, or what may have been done to it.
>>
>> Sure but applications should either validate or trust the local
>> validator loading the zone. So that limits the discussion to
>> glue/NS only.
>>
>>> I'm not sure this is what you mean by "speed of execution" but as an example, my implementation (which uses ldns) can calculate and verify a SHA256 signed root zone digest in under 100 msec.
>>>
>>> $ sort --random-sort root.zone.signed | ldns-zone-digest -t -p 2 -c -v .
>>> Loading Zone...22539 records
>>> Remove existing ZONEMD...
>>> Add placeholder ZONEMD...
>>> Calculating Digest...Done
>>> Calculating Digest...Done
>>> Found and calculated digests do MATCH.
>>> TIMINGS: load  142.18 calculate   82.72 verify   52.24 update    0.00
>>
>> I don't see it validating the ZONEMD RRSIG here ? :P
>>
>> Paul
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop