why ssb doesn't have capability negioation

[dominictarr]

I didn't see this before, but just wanted to give some context on why we didn't do this in the first place.

Firstly, I was aware that the negotiation phase it self has been a source of multiple vulns in TLS or SSH, down grade attacks, etc.

Then this discussion with ipfs: ipfs/kubo#34
I saw there are two strong positions: 1. use a well known protocol, such as TLS. or 2. use something so simple that it's obviously secure.

I ended up reluctantly going with 2 because in the process of even figuring out exactly how TLS worked (such that we could use it for a mutually authenticated p2p protocol) I ended up with enough knowledge to design one. Also, strongly influenced by the work of djb - don't make crypto protocols configurable, that is just adding footguns.

Anyway, instead of having handshakes, the encryption protocol is part of the address. described here: ssbc/ssb-server#139 which became https://github.com/ssbc/multiserver
in particular see the motivation section

We've been adding more protocols, but we havn't added a new secure channel yet. (although @keks is working on one) currently pubs are identified in pub messages (which was created before we even had this idea) so they don't use multiserver addresses... but once some one merges this the next thing redoing pub messages (also the last step of the user-invites saga)

[keks]

Clarification: I'm working on a key exchange protocol, not a secure channel protocol. So I (currently) don't propose to move away from box-stream (though I think that given that even ssh had trouble with getting their stream encryption right and switched to intermaclib, I'm not too confident ours is 100% fine).

[dominictarr]

@keks clarification: you mean you are doing a the handshake part, but not the symmetric bulk stream protocol?

[keks]

Yup Am 9. September 2018 05:44:49 MESZ schrieb Dominic Tarr <notifications@github.com>:

…

@keks clarification: you mean you are doing a the handshake part, but not the symmetric bulk stream protocol? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1 (comment)

-- Sent from mobile.