From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9ba4246f4fec89c0bfe8e4e5e85f4fa6@felloff.net> Date: Fri, 25 Dec 2015 00:49:00 +0100 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] using tls-psk cipher suits vs roll our own handshake Topicbox-Message-UUID: 7ae6b016-ead9-11e9-9d60-3106f5b1d025 > 5) seems to much effort to do right/securely, no? kind of. one would indeed need to authenticate the messages somehow, and maintain lists of usefull cipher suits ect. which basically is what tls already does. right now, i'm kind of in favour for using tls-psk (rfc4279) even if it might seem like overkill at the moment. (its easy, just wrote the code) -- cinap > On Thu, Dec 24, 2015 at 4:45 PM, 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 > >