From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <9ba4246f4fec89c0bfe8e4e5e85f4fa6@felloff.net> References: <9ba4246f4fec89c0bfe8e4e5e85f4fa6@felloff.net> Date: Thu, 24 Dec 2015 20:34:05 -0600 Message-ID: From: Alex Weber To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113cd96cff1de50527afc96a Subject: Re: [9fans] using tls-psk cipher suits vs roll our own handshake Topicbox-Message-UUID: 7aea96c2-ead9-11e9-9d60-3106f5b1d025 --001a113cd96cff1de50527afc96a Content-Type: text/plain; charset=UTF-8 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, 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, 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 > > > > > --001a113cd96cff1de50527afc96a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Has TLS-SRP been cons= idered instead of TLS-PSK?

If the secret used for TLS-PS= K comes entirely from a password, then TLS-SRP might be a better choice. Th= at's the extent of my knowledge of TLS-SRP. :)

-Alex

On Thu, Dec 2= 4, 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,=C2=A0 <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.<= br> > >
> > 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
> >


--001a113cd96cff1de50527afc96a--