Are there any security issues when replacing the SHA-256 initialisation values? As RFC 4634 describes in section 6.1, SHA-256 is initialized using eight 32-bit words.

These were obtained by taking the first 32 bits of the fractional parts of the square roots of the first eight prime numbers:


H(0)0 = 6a09e667  
H(0)1 = bb67ae8  
H(0)2 = 3c6ef372  
H(0)3 = a54ff53a  
H(0)4 = 510e527f   
H(0)5 = 9b05688c  
H(0)6 = 1f83d9ab  
H(0)7 = 5be0cd19



These are obviously meant to be "nothing up my sleeves" numbers.

Assuming interoperability — read: compatibility between users — isn't an issue, I've got the following questions:


Are there any security issues related to replacing those SHA-256 initialisation values?

The plan is the one-time use of a CSPRNG to get alternative values for a specific (in-house) implementation; which I presume to be a safe way to get good alternative values. Please correct me when this assumption is wrong.
Are some initialisation values worse than others? 

In other words: is the Merkle–Damgård construction, and/or the SHA-2 algorithm design as a whole, susceptible to weak initialisation values along the lines of 0-key problems as applicable to cipher analysis? Or could we set them all to zero without any impact on cryptographic security?




NB: pointers to related research paper(s) welcome, but not a "must".
Random IVs are fairly clearly ok. NIST secure hash standard defines SHA-512/t with arbitrary t and different IV values that are themselves outputs of SHA2, and Merkle-Damgård hashes basically do the same internally when you have a multi block massage. There should be no reason you could not do the same with SHA-256 or with another PRNG generating the IV values.

Nonrandom IVs are theoretically a different matter. Current (partial) attacks on SHA2 work on the compression function and find collisions for any predetermined IV/chaining value. However, at least in principle some values could be easier to attack. That would not break the whole hash as long as the number of weak IVs is negligible.
(As in the case of the Malicious SHA1 linked in the comment by CodesInChaos, but with round constants instead of IV.)