> On 26 Jul 2018, at 18:40, Wessels, Duane <[email protected]> wrote: > > Ondrej, > > Thanks, I think thats a fair point. I was of course hoping to not create yet > another IANA registry. > > If the ZONEMD RR included a count of records as suggested by Paul Wouters > would you then be comfortable > just using the DS hash algorithms?
That’s probably question you need to ask some cryptographer, so take my opinion with a grain of salt. If <n> is the number of ZONEMD-covered records, then the probability of collision attack gets higher. So, unless I am mistaken, the delegation heavy zones would be especially susceptible to a collision attack. Does it make sense? Ondrej -- Ondřej Surý [email protected] > DW > > >> On Jul 25, 2018, at 8:47 PM, Ondřej Surý <[email protected]> wrote: >> >> Hi Matt, and other authors, >> >> with my cryptoplumber[1] hat, I am strongly opposed to using SHA-1 and GOST >> R 34.11-94 for ZONEMD. >> >> It is my understanding, that the specific usage of hashing function in the >> DS record improves the collision >> resistance of the algorithm, because the input data is so small and it has >> to be a valid DNSKEY record[2]. >> >> For ZONEMD, this isn’t true, as you can (in theory) feed the zone with >> infinite amount of non-DNSSEC-signed >> data (GLUEs, delegations) thus making the collision attack feasible. >> >> Thus I believe, the Section 2.1.2 must be changed to disallow usage of >> algorithms with weakened collision >> resistance (and algorithms deprecated by the Russians themselves :). It >> wouldn’t be enough just to discourage >> SHA-1 for creating the ZONEMD, but it needs to be forbidden to use it for >> validating such record. >> I think that new IANA table for ZONEMD must be established, because the >> security properties of the algorithm >> usage are different in DS and ZONEMD records. >> >> Thanks, >> Ondrej >> >> 1. I would be happy if any real cryptographer would chime in. >> >> 2. It doesn’t have to be valid DNSKEY if you just want to cause ruckus, but >> if you are able to inject invalid DS >> records, you might as well cause damage at other levels of the DNS tree. >> >> -- >> Ondřej Surý >> [email protected] >> >>> On 23 May 2018, at 17:32, Weinberg, Matt >>> <[email protected]> wrote: >>> >>> Greetings dnsop, >>> >>> We’ve posted a new version of draft-wessels-dns-zone-digest. Of note, this >>> -01 version includes the following changes: >>> >>> • Warren Kumari and Wes Hardaker have been added as coauthors. >>> • Several points of clarification in wording and descriptions. >>> • Removed the requirement to sort by RR CLASS. >>> • Added a Change Log section. >>> >>> Warren and Wes had started on a very similar but unpublished draft, which >>> we should've remembered. Thanks to them for agreeing to join this document >>> as coauthors. >>> We plan to ask for time on the dnsop agenda in Montreal. Your feedback is >>> welcome and appreciated. >>> >>> Thanks. >>> >>> ---- >>> >>> A new version of I-D, draft-wessels-dns-zone-digest-01.txt >>> has been successfully submitted by Matt Weinberg and posted to the >>> IETF repository. >>> >>> Name: draft-wessels-dns-zone-digest >>> Revision: 01 >>> Title: Message Digest for DNS Zones >>> Document date: 2018-05-17 >>> Group: Individual Submission >>> Pages: 13 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-wessels-dns-zone-digest-01.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-wessels-dns-zone-digest-01 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-wessels-dns-zone-digest >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-wessels-dns-zone-digest-01 >>> >>> Abstract: >>> This document describes a protocol and DNS Resource Record used to >>> provide a message digest over DNS zone data. In particular, it >>> describes how to compute, sign, represent, and use the message digest >>> to verify the contents of a zone for accuracy and completeness. The >>> ZONEMD Resource Record type is introduced for conveying the message >>> digest data. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> DNSOP mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> _______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
