Hi, Has TLS-SRP been considered instead of TLS-PSK?
If the secret used for TLS-PSK comes entirely from a password, then TLS-SRP might be a better choice. That's the extent of my knowledge of TLS-SRP. :) -Alex On Thu, Dec 24, 2015 at 5:49 PM, <cinap_len...@felloff.net> wrote: > > > 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, <cinap_len...@felloff.net> 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 > > > > >
