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_lenrek@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_lenrek@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
> > >
>
>