But, TLS is a huge spec, and I think the OpenSSL guys are going to have more experience in things like "Older (and widely deployed) F5 networking devices attempt to parse a TLS Handshake as SSLv2 first, which means that due to the overlapping structure, an SSLv3/TLS client-hello of length 256 - 511 bytes, it can't tell if a certain byte is a "message type" of 1 (SSLv3/TLS) or it is the "length high bits" to be 1 (SSLv2). Therefore, despite no mention in the spec, it's useful to pad out the CLIENT_HELLO to remove the ambiguity." (Just to use a recent example)
TLS is a horrible mess of a spec, and the real-world implementations are even grittier. While I'm not knocking the OpenBSD guys at all (and I think what they're doing is great), let's not forget that OpenSSL got it's place because despite the code quality, it's one of the most fully-featured TLS stacks out there due to the knowledge and experience of it's developers. I hope to see lots of code flowing in both directions between the two projects.
I've actually been wondering lately, if a for of openssh would be a good idea, with the goal of ripping out version 1 support, some other cruft, and eg: arcfour and other algorithms that seem a bit redundant and potentially dangerous (to me) these days.
So far, I'm thinking that the odds that I'd introduce some horrible bug (either along the lines of the Debian ssl keygen bug) or perhaps more likely increase vulnerability to timing attacks outweighs the potential benefits (a tighter, more transparent code base, with fewer features and hopefully fewer bugs).
Since they also develop OpenSSH, wouldn't that qualify them to also work on the algorithm parts?