On Wed, 1 Mar 2017, Roy Arends wrote:
[cut previously answered items]
The point is not the chain itself, but the right hand side of the first CNAME
in a chain. Make it long enough and you’ll have enough bits.
Still very constrained, 63 octet chunks with a total of 253 octets.
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.
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.
Vendors are on this list and usually fairly vocal. I welcome their input.
Agreed.
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.
To compare, browsers generally are unwilling to kill something if it
affects more then 0.01% of browsers.
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. 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.
Migration should be done responsibly.
Sure. But a migration doc is something else. This is not it.
It is part of it. Whatever is no longer mandatory to implement is given a
death sentence. The whole point of this document, as we did with 7321 and
4307 in IPsec, is to make things orderly but firmly. Walk, not run. Which
is why we made the distinction between validators and signers. And we
really need the help of the signers to gradually stop signing with the
insecure algorithms while giving them a chance to warn their users,
and more importantly, warn the owners of automated shell scripts.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
