> On 1 Mar 2017, at 01:56, Paul Wouters <p...@nohats.ca> wrote: > > On Tue, 28 Feb 2017, Roy Arends wrote: > >>> We can't stuff PDF prefixes into this, >> >> We don’t need to. >> >>> there are a lot less bytes >>> for an attacker to play with. >> >> A CNAME chain will give you plenty of bytes to futz with. > > None of the SHA1 hases we use are covering a chain of records.
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. 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. All in all. The assumption that there are a lot less bytes for an attacker to play with is incorrect. > >>>> Please also refrain from using MUST- SHOULD+ and SHOULD-. >>> For this SHA1 case or in general? >> >> In general. > > I disagree then. Did you read the motivation of why we use > those terms to clarify that we expect an algorithm to be > promoted or demoted in a future update? Yes. I've read it. It is silly. I expect any algorithm to be demoted in a future update. I expect any algorithm to be promoted in a future update. I expect world peace too. And a pony! I understand that you want to reflect, at the time of writing, the expectation that in the future some algorithms are king, some algorithms were king and some algorithms will be king. However, the only thing you _can_ state is what you know at the time of writing: some algorithms are king, SHA1 algorithms were king. Anything else is guesswork. Why don’t you leave these future predictions to a future update. > >>> I'd say we could update the DNSSEC >>> Signing entry from MUST- to SHOULD NOT >> >> Good. That is exactly my request. > > This is still only meaningful if the signer software vendors > in general agree with this. If they will just ignore this > document, then I feel there isn't much point in proceeding > with it. Vendors are on this list and usually fairly vocal. I welcome their input. > >>> but I would leave SHA1 for >>> DNSSEC validation at MUST-. >> >> I’d say you have to update that as well to SHOULD NOT. > > 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? > > Migration should be done responsibly. Sure. But a migration doc is something else. This is not it. Roy _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
