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

[Charles Forsyth]

On 25 December 2015 at 03:03,  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.

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

[Charles Forsyth]

On 29 December 2015 at 18:34, Charles Forsyth 
wrote:

> extension of the protocol to the occasional new protocol.


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

Re: [9fans] Pi updates

[Brian L. Stuart]

On Mon, 12/28/15, Anthony Sorace  wrote:
> And yes, I’d be interested in seeing your
> slides, although you’ve already given me
> enough to keep my busy for a bit.
 
Anthony,
I've put the slides up in the directory at:

http://cs.drexel.edu/~bls96/plan9/

The class met one night a week and we have 10 week
quarters.  So there are only 9 sets of slides.  There's not
a lot of textual meat in them.  I tend to have a lot of figures
I talk over with some outline-level textual material.

BLS

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

Re: [9fans] Pi updates

[Brian L. Stuart]

> Excellent.  I had suspected that statement was too restrictive, but hadn't
> seen the errata or gotten around to checking on a scope.  I'll update that
> today.
 
New versions posted.  spiclock() now rounds the divisor up to the smallest
even number that results is a clock rate less than or equal to that requested.
Let me know if you run into anything else that needs attention.

BLS

Re: [9fans] Pi updates

[Brian L. Stuart]

> but http://raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md
> has an erratum suggesting "power of 2" should be "multiple of 2".  I have
> been using a default divisor of 250 for a 1MHz clock, and that's the frequency
> I see on my oscilloscope.

Excellent.  I had suspected that statement was too restrictive, but hadn't
seen the errata or gotten around to checking on a scope.  I'll update that
today.

Thanks,
BLS

Re: [9fans] Pi updates

[Richard Miller]

Thanks, Brian - that all looks very useful to make the pi more amenable
to hardware tinkering.

One small suggested amendment: your spiclock() says this -

/*
 * According the Broadcom docs, the divisor has to
 * be a power of 2.  This code rounds up so that the
 * resulting clock is the highest value no greater than
 * what's requested.
 */

but http://raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md
has an erratum suggesting "power of 2" should be "multiple of 2".  I have
been using a default divisor of 250 for a 1MHz clock, and that's the frequency
I see on my oscilloscope.