Well, this has crossed my mind a few times, I actually downloaded a few ssl libs the other day to have a look around...
In any case, while being a good (verbose) initiative, there are some technical flaws, like:
1) Reinventing a secure handshake - dangerous, it took the ssl folks 3 versions, and hopefully they knew more than us about this stuff...
2) No perfect forward secrecy - lose the key to someone and any recorded data can be decrypted (authorities spring to mind)
3) No algorithm negotiation - locked to one algorithm pair, and algorithms tend to lose credibility over the years
4) No separation between adc and encryption (what's that cid etc doing in the initial negotiation?)
5) Still identifyable as ADC with all the packetfilter problems that follow
6) Server speaks first - in general the server shouldn't waste resources sending data until the client has made an effort
7) On a more philosofical note - who is this encryption targeted against? ISP listening in? hub listening in? neighbour on the same subnet listening in? As I read it there's one encrpytion layer between hub and client and then another one in that between clients when speaking through the hub...those are two completely separate use-cases and should thus imho be covered in separate extensions - if encrypted c-c messages through the hubs should be supported at all...
8) No authentication - vulnerable to the good ole' man in the middle attack
9) I can probably thing of more - these were just the first things that sprung to mind...

Instead I was just about to do something a lot more simple with dc++ and adchpp; SSL tunneling for both c-c and c-h connections, solves all those issues above. there are a few details to be considered though, mainly regarding key distribution, i e should the hub sign keys of its users (probably not) or should all keys that can be verified by querying the user for their hash with a d message be seen as valid? One potential issue is that we can't up-negotiate the protocol to encrypted mode if we want to make it http-lookalike - which means that the server must either have a unique port open or use some ugly heurestics (or perhaps best - support only encrypted connections)...

/J