From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Kenny Lasse Hoff Levinsen In-Reply-To: <71b465e856dfbd4b3ce36c3a3ae6bf03@felloff.net> Date: Tue, 29 Dec 2015 21:31:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <71b465e856dfbd4b3ce36c3a3ae6bf03@felloff.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] using tls-psk cipher suits vs roll our own handshake Topicbox-Message-UUID: 7b452466-ead9-11e9-9d60-3106f5b1d025 1. This could work, although if you add =E2=80=9Cif things break, try = again with different algo=E2=80=9D, 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=E2=80=99t 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=E2=80=99s 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=E2=80=99t think it=E2=80=99s 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, cinap_lenrek@felloff.net wrote: >=20 > 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. >=20 > when switching to tls, we have a few options: >=20 > 1) do as we do with ssl, client sends what cipher and hash alg > it wants as a string before calling pushtls(). >=20 > 2) use fixed cipher like chacha20/poly1305 aead unconditionally. >=20 > 3) use fixed cipher initially, and after that, renegotiate > cipher (devtls can change secrets and ciphers inband). >=20 > 4) use standard tls handshake with PSK cipher suits. >=20 > 5) make our own little cipher negotiation handshake protocol. >=20 > suggestions? >=20 > -- > cinap >=20