A few questions

[pingpong71]

This is an interesting project but I have a few questions that don't seem to be raised in the readme.

1. What kind of security audit and review has been done over the project ?
2. Has any team or company been approached thus far for security review or are you just hoping since its a public github it will get done at some point ?
3. Has there been any approach to the openssh team to roll in any of the changes (which from my cursory reading is really over certificate handling but I'm probably wrong here) ?
4. If the answer to number 3 is yes - do you have a link to any discussion with that team I could review ?

[francoismichel]

Hey, thanks for this issue that summarizes very well common questions currently raised by people.
I'll take this opportunity to answer all these questions at once.

What kind of security audit and review has been done over the project ?

Exactly two people wrote the article: Olivier Bonaventure my thesis advisor and myself.
I was the only one that wrote the code. A few people in the acknowledgements read the article and gave comments on it, some of them about security aspects. You can find these people in the acknowledgements of the article. But they gave a rough review, they are not by any means advocating that there is no possible security issue, they just provided much appreciated comments, help and feedback. Among these people that helped, you will find Olivier Pereira, professor in security at UCLouvain. I wrote the implementation with security in mind and try my best to make it as robust as possible.

But let's be clear: security issues will occur, and that is the case for every written piece of software, and I am fine with that. I hope that people will find these issues and contact me in a responsible disclosure manner.
Personnally, I already run public instances of SSH3 myself. If your are scared of doing the same, it is possible to hide your SSH3 server behind a secret link using the -url-path feature. Using that, no actual code of the ssh3-server is run while the user or attacker does not know the secret URL behind which the server is hidden. I think that is a good way to try out SSH3 while severely reducing the actual impact of potential security issues. Note that security issues may still occur from attackers that you "semi-trust", i.e. attackers that also legitimately have access to your remote host and that may try to connect as root, or as another user.

Has any team or company been approached thus far for security review or are you just hoping since its a public github it will get done at some point ?

Both. This project was released as an artifact for a submitted journal paper. I strongly believe in the project and the ideas, but I was not expecting that level hype that soon, especially before the article was even published. So I was mainly relying on community feedback to make the project stronger and more robust. Now, I also started discussing with people doing audits, if it goes somewhere concrete, everything will be made public for everyone. I welcome everyone to help me on that. I just hope that people will release security issues in a reponsible disclosure manner.

Has there been any approach to the openssh team to roll in any of the changes (which from my cursory reading is really over certificate handling but I'm probably wrong here) ?

Yes, I contacted one OpenSSH developer a few weeks ago, before I released the project. The mail exchange was courteous and short. The takeway was that they have no appetite in using either QUIC or TLS anytime soon, one of the reason is that it would be breaking a good part of the existing mechanisms, compatibility with OpenSSH certs, etc.
This is totally fine, I can get why they don't want to do that. I love OpenSSH, I use OpenSSH everyday and think the tool is amazing. I still think the ideas presented in our SSH3 paper are really cool and I am all enthousiast about it.

If the answer to number 3 is yes - do you have a link to any discussion with that team I could review ?

Sorry, I dare not making it public. :-/

I will also give a comment about the name, some people complain a bit about the name ssh3 and the fact that it is not related to OpenSSH.

Please keep in mind that this project was originally supposed to hold the artifacts for our article called "Towards SSH3: [...]". This article imagines how SSH could be revisited and how the new version could look like. Calling the repository SSH3 was therefore totally logical to us, especially that we were not expecting that level of traction before the article was released. Honestly, I do not want to change the name, the name of the repository is clear, it is called francoismichel/ssh3 and not openssh3/ssh3 nor ssh3/ssh3. We have been honest in our approach and really believe that it is a first step towards a new version of SSH. Our goal is to push this work towards standardization and spark interest at IETF. If OpenSSH makes a version 3 of their software, it will probably be called ssh and I let it to them, it will be great and I will use it. People choose how they call their executable and distro maintainers can choose if they call it ssh3 or whatever, I am fine with that. It is called ssh3 in the Github Releases because this project is SSH3, but when compiling Go executables, you can easily give it the name you want. :-)

Thank you for these questions, it is a perfect timing to answer all that !
I'll keep this issue open, refer it in the README and use it for discussions.

Thank you for the support and comments, let's make it great all together ! 🚀

[mpiraux]

Is there anything lacking in François' answers to your questions ? If not, can we mark this as close or do you see further actions ?