[9fans] using tls-psk cipher suits vs roll our own handshake

[9fans] using tls-psk cipher suits vs roll our own handshake

[cinap_lenrek]

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

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

[Iruatã Souza]

5) seems to much effort to do right/securely, no?

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
>

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

[cinap_lenrek]

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

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

[Alex Weber]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2549 bytes --]

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

[cinap_lenrek]

no. the "shared secret from the authentication process" refers to
the random key generated by the AS (and transported to both the server
and client in tickets that are encrypted with the servers/clients key).

the situation is that server and client already authenticated each
other and have a random shared secret key for the "session" and now
want to setup encryption on the channel.

the functionality that is desired is to be able to "negotiate" the
cipher suits and record layer protocol versions.

--
cinap

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On 25 December 2015 at 03:03, <cinap_lenrek@felloff.net> wrote:

>
> the functionality that is desired is to be able to "negotiate" the
> cipher suits and record layer protocol versions.


I could never work up much enthusiasm for TLS because it is needlessly big
and complex, but still got important things wrong.
I never saw the advantage of TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA as opposed
to exchanging a few bits of text,
allowing easy extension of the protocol to the occasional new protocol.

The main reason for using it for 9P would be to make it easier to
communicate with 9P services running on other platforms,
but my experience with Java was that in the end, the service provider
factories couldn't make anything I wanted to use.
In particular, I couldn't replace the dreadful CA-oriented x.509
certificates and asn.1 by something else. Anything, really.
I also wasn't given planning permission to build my own factory. You get
all the bugs, though.

[-- Attachment #2: Type: text/html, Size: 1792 bytes --]

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 224 bytes --]

On 29 December 2015 at 18:34, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> extension of the protocol to the occasional new protocol.


Sorry, that second "protocol" was supposed to be algorithm or technique.

[-- Attachment #2: Type: text/html, Size: 523 bytes --]

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

[Kenny Lasse Hoff Levinsen]

1. This could work, although if you add “if things break, try again with different algo”, 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’t 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’s 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’t think it’s 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:
> 
> 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
> 

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

[cinap_lenrek]

> I could never work up much enthusiasm for TLS because it is needlessly big
> and complex, but still got important things wrong.
> I never saw the advantage of TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA as opposed
> to exchanging a few bits of text,
> allowing easy extension of the protocol to the occasional new protocol.

if you dont want negotiation, then we need to come up with new default
encryption scheme that will work perfectly for a long time. i cannot promise
that. with negotiation, stuff will get more complex but at least we can
fix and upgrade one machine at a time and get the best possible option
for each conversation.

what would you do?

--
cinap