1. This could work, although if you add “if things break, try again with different algo”, you get 5.
2. While a good cipher, seems like something that might get us stuck in the future. 3. This seems a bit complicated, and is in essence 5 performed over a fixed cipher. 4. makes sense. I don’t think the overhead will be too bad. We get the Client/ServerHello/ChangeCipherSpec dance, which is of course more complicated than necessary, but also fairly well known, and as long as the ciphers allowed by the server are limited, the security concerns of this handshake should be minimal. 5 takes time to design properly. There’s not many attacks to protect against, but it should still be thought through. I think 4 (standard tls handshake) is the safest bet, especially if we want it to be decently strong. We could make 5 as good and 3 better, but I don’t think it’s really worth the effort at the current time (and 3/5 does require effort if it has to be done right). kenny // joushou > On 24 Dec 2015, at 17:45, [email protected] wrote: > > plan9 currently uses the shared secret from the authentication > process with ssl and rc4 cipher for encrypting traffic for > exportfs and the cpu services (pushssl()). the cipher can be > changed by the client by providing command line parameters, > tho there is no real negotiation going on. if the server > doesnt like the cipher from the client, the connection just > breaks. > > when switching to tls, we have a few options: > > 1) do as we do with ssl, client sends what cipher and hash alg > it wants as a string before calling pushtls(). > > 2) use fixed cipher like chacha20/poly1305 aead unconditionally. > > 3) use fixed cipher initially, and after that, renegotiate > cipher (devtls can change secrets and ciphers inband). > > 4) use standard tls handshake with PSK cipher suits. > > 5) make our own little cipher negotiation handshake protocol. > > suggestions? > > -- > cinap >
