> On Mar 24, 2015, at 10:41 AM, Matthäus Wander <matthaeus.wan...@uni-due.de> > wrote: > > * Paul Hoffman [2015-03-24 13:57]: >> On Mar 23, 2015, at 6:23 PM, Jan Včelák <jan.vce...@nic.cz> wrote: >>>> - The statement about NSEC3 "offline dictionary attacks are still possible >>>> and have been demonstrated" doesn't take into account trivial changes that >>>> an operator can choose to take if they are really concerned about offline >>>> dictionary enumeration (with the trade-off being zone size). >>> >>> Please, can you clarify which trivial solution in particular do you mean? >> >> Sure. When signing the zone, instead of creating one NSEC3 record for a gap, >> you create 10 or 100 with random intervals between the two hashes. That way >> an attacker is more likely to get results that will not match dictionary >> entries. > > This slows down the online hash collection but not the offline > dictionary enumeration. The attacker will have to send 10 or 100 times > as many queries (which of course the server administrator pays by having > to send 10 or 100 times as many negative responses). > > In the offline attack, the performance is dominated by the effort for > hashing the input dictionary. Whether you're matching the output against > 1000 or 100000 hash values has little influence on the total performance.
Completely true. However, the existence of NSEC5 is predicated on the idea that a zone admin cares so much about zone enumeration that they are willing to risk having their zone appear unsigned to resolvers that do not implement NSEC5. If that zone admin finds that cost too high, but has lots of CPU available during signings, they should know that they have that alternative. Again: a proposal for an operational change to DNSSEC needs to be explicit about the tradeoffs, particularly when one of the options is "you will be considered unsigned by some resolvers when you implement this". The current draft is not have this. --Paul Hoffman
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
