Question: Sessions and TLS

[jmhobbs]

Could a properly configured TLS connection take the place of the network session key description here?

[jmhobbs]

So, from my understanding of the documents, the network session key exchange document is part of the specification of a lower level TCP based transport?

The communications within the SDMP are network-agnostic. They can be communicated over HTTP, plain TCP, sent in an email, or even sent over SMS.

From the communication document, it would appear that so long as the communication is secured in a forward safe manner, the mechanism isn't important.

Every attempt should be made to implement forward secrecy. This means that network communications should use session-based encryption keys. See the basic network specifications for an implementation over TCP.

So if I use HTTPS as the transport with properly configured SSL, it should be fine.

Am I taking crazy pills?

[saibotsivad]

Sorry for the long delayed response. I took a couple weeks off work in order to buy a house!

You are not, in fact, taking crazy pills. I'll write down my thoughts, possibly in a rambly manner, and I'd appreciate your input.

These are the issues at stake:

1) Network communication must be secure in a forward safe manner. This is usually done by using something like the Diffie-Helman, where you can guarantee some semblance of token uniqueness. 2) Network communication must be secured with known and trusted keys. With typical HTTPS, you use root CA certs and trusted certs to verify the server, but the premise of the SDMP is that this approach is fundamentally faulty--there is no convenient way to manage and verify the certs that you use to connect.

One additional issue was that the network traffic of the SDMP was very simple, compared to HTTPS, so I didn't see any reason to specify the protocol over HTTPS. Also, in my experience poking around with diaspora I found that many people had difficulty getting HTTPS configured securely, so they basically just hacked a non-secure protocol in place. I didn't want to fall into the same trap.

Because of this, and a handful of other reasons primarily involving simplicity, I opted to write specs for a network communication protocol that would be very simple.

HOWEVER, with all that said: A person could write an "extension" to the SDMP and run it over HTTPS. I don't know if I made it clear in the docs, but you could potentially write specs for the SDMP over any other protocol, and that would be valid.

The primary issue with using any communication channel is that the tokens used to initiate a session key must be signed by the node opening the channel. In effect, you must not use signed CA certs or any of that nonsense.

Another issue with initiating an HTTPS connection via HTTP upgrade is that the headers and so on from the initial HTTP connection are in plaintext. So if you do write specs for HTTPS, you'd want to limit the acceptable headers in an HTTP-upgrade request.

[jmhobbs]

Thanks! And wooo for houses! :)

Regarding item 2,

2) Network communication must be secured with known and trusted keys. With typical HTTPS, you use root CA certs and trusted certs to verify the server, but the premise of the SDMP is that this approach is fundamentally faulty--there is no convenient way to manage and verify the certs that you use to connect.

Is it assumed that node public keys will be exchanged out of band? I'm a bit confused on how communication gets bootstrapped.

I'm probably going to drop the HTTP based node link for now and just use it as a local frontend for users to interact with the server.

[saibotsivad]

It's anticipated that users will exchange public keys out of band. There's some good questions about how to accomplish that, and I hope to resolve that within a "social network" context that I'll be publishing once I've settled down with this more.