9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Kenny Lasse Hoff Levinsen <kennylevinsen@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] using tls-psk cipher suits vs roll our own handshake
Date: Tue, 29 Dec 2015 21:31:16 +0100	[thread overview]
Message-ID: <AA2C9021-5DA5-4077-BD02-311E6B17B504@gmail.com> (raw)
In-Reply-To: <71b465e856dfbd4b3ce36c3a3ae6bf03@felloff.net>

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
> 




      parent reply	other threads:[~2015-12-29 20:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-24 16:45 cinap_lenrek
2015-12-24 17:09 ` Iruatã Souza
2015-12-24 23:49   ` cinap_lenrek
2015-12-25  2:34     ` Alex Weber
2015-12-25  3:03       ` cinap_lenrek
2015-12-29 18:34         ` Charles Forsyth
2015-12-29 18:35           ` Charles Forsyth
2016-01-03  4:03           ` cinap_lenrek
2015-12-29 20:31 ` Kenny Lasse Hoff Levinsen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AA2C9021-5DA5-4077-BD02-311E6B17B504@gmail.com \
    --to=kennylevinsen@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).