> On 1 Mar 2017, at 17:41, Paul Wouters <p...@nohats.ca> wrote: > > On Wed, 1 Mar 2017, Roy Arends wrote: > >> An attacker needs two successive 512 bit blocks and a prefix. >> However, you _do_ hash a chain of records. Forget CNAME, take a DNSKEY RRset >> with a few DNSKEY records in it. A fake 1024 bit key aligned just right will >> do the trick. > > Those are still intersparsed with mandatory DNS markers, unlike the > variable size giant blob inside a PDF.
This is not true. The shattered.io pdf files contain an embedded jpeg. The difference between the files is in the jpeg comment. The size of the difference is 128 bytes. These are two consecutive 64 byte inputs. The two versions hash to the same output, given the prefix. The prefix is 192 bytes, and contains the PDF header and the start of the embedded JPEG. This could have been any arbitrary content (such as owner name, TTL, class, type, etc) as long as it is a multiple of 64 bytes (size of input block for sha1). These 128 bytes can be the content of the DNSKEY. It would therefor not have to be “intersparsed with mandatory DNS markers”. >> Why don’t you leave these future predictions to a future update. > > Because having multiple MUST or SHOULD entries does not help the > implementer knowing which ones are more important for the future, > and which ones are more there for legacy deployment reasons. Implementer should follow spec. Spec sez MUST or SHOULD. Now it says MUST- MUST+ MUST SHOULD- SHOULD+ and SHOULD. Very confusing. Which one should be implemented? How do I add a grade of importance to specific algorithms, while the protocol itself doesn’t care. DNSSEC has no signalling which algorithm is more or less important in the future. > >>> That is just unreasonable. Do you want half the the DNSSEC >>> signed zones in the world to go insecure or bogus? >> >> I have different numbers, but I do prefer a zone going bogus rather than >> falsely secure. >> Can you please show where you got the “half the the DNSSEC signed zones in >> the world to go insecure or bogus” numbers, or are you just picking a >> convenient number to make your argument? > > Well, secspider is pretty good? http://secspider.verisignlabs.com/stats.html > > 1,641,133 Production DNSSEC-enabled zones > > RSASHA1-NSEC3-SHA1 1,320,540 > RSA/MD5 21 > RSA/SHA-1 [RSASHA1] 123,575 > RSA/SHA256 [RSASHA256] 2,332,855 > > Number of keys does not directly map to number of zones (we have 3.6M > keys and 1.6M zones) but this shows 1/3 of the keys are still using > SHA1. Okay, so you did make it up. 1/3 is not 1/2. How many of those SHA1 keys are used in conjunction with non-SHA1? That is, how many would still be secure when SHA1 is ignored? > > To compare, browsers generally are unwilling to kill something if it > affects more then 0.01% of browsers. This is nonsense. > Clearly the goal of our draft is moving this in the right direction, > but saying you want to change the security of a third of the zones > to make a point about SHA1 does more damage than good. Again, how many zones does it affect when most of them have SHA2 as well? The damage I’m trying to avoid is the false sense of security you are inflicting by not taking the proper action. It is because the lack of action from specs like these that BIND-9.11.0 still ships with SHA1 defaults: $dnssec-keygen Version: 9.11.0 Options: -a <algorithm>: <snip> (default: RSASHA1, or NSEC3RSASHA1 if using -3) > And the minus > symbols you so dislike is our way or signaling to people to take > note that something we must support today, is being moved to the > chopping block. oh dear. I see that further discussion is useless. Roy _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
