Implemented a Basic TLS

[Bren2010]

Proposed solution as a simple, secure, and modular transport layer.

Uses peer keys for signing only (which they probably should be restricted to), and a shared key is derived through ECDH. Provides forward secrecy, data secrecy, data integrity, and mutual authentication. Borrows the idea of cipher suites/negotiation from TLS for modularity.

Protocol:
Step 1: Hello = (Random, MultiPublicKey, Supported Algorithms)
Step 2: Exchange = (EECDH Public Key, Sig(Hello1 || Hello2 || EECDH Public Key))
Step 3: Finish = E("Finish")

Atm, it hasn't been integrated with the rest of the code base yet.

Peer review/suggestions welcome, as always.

[whyrusleeping]

I would prefer if all of this wasnt a single anonymous function inside of handshake, if we could break this down a little that would be nice (and slightly more readable!)

[jbenet]

tl;dr: this is not yet audited. we need to audit a lot of stuff, so merging in with the massive disclaimer that this is not yet known to be secure.

17:58 <whyrusleeping> jbenet: look at the changes to the handshake function
17:59 <whyrusleeping> it looks good to me, and appears to work fine. but i just wanted your once over
18:02 <•jbenet> mmm worried about signing off on security stuff by just looking over.
18:02 <whyrusleeping> ah, yeah
18:02 <•jbenet> I mean we need to go through and audit a lot of stuff anyway-- perhaps TRTTD is to merge in and put a massive disclaimer that it's not yet secure.
18:03 <•jbenet> (in the code, i mean)
18:03 <whyrusleeping> yeah? i can do that
18:03 <whyrusleeping> im part of the security group at my university, we can do an audit as a club event to help out
18:03 <•jbenet> that could be great
18:04 <•jbenet> it'd be nice to reach a functionality feature freeze
18:04 <whyrusleeping> okay, ill do the merge then?
18:04 <•jbenet> and then go back to a) polish interface, b) reimplement broken things, c) audit security
New messages
18:04 <•jbenet> yeah, i'll just add this discussion to the PR

[jbenet]

cc @perfmode @cleichner if you want to help CR something

[dominictarr]

doesn't this leak metadata - who is connecting to who? isn't it possible to be encrypted from the first byte by doing the EECDH exchange first?

[Bren2010]

@dominictarr Yep. But afaik IPFS has no interest in anonymity and following TLS' pattern of authenticating and verifying the secure channel before using it for anything important makes me feel warm and fuzzy inside (and is probably a good way to avoid strange vulns).

[jbenet]

@dominictarr Unless you know who you're connecting to beforehand, a listener you're connecting to will have to get your public key. But yes, fair point, there could be two modes, for initializing connections to new unknown public keys, and for known ones.

[dominictarr]

If you are gonna use something similar to tls why not just use tls?
tls has had more than a few strange vulnerabilities... but it's well studied.

I think there are two strong positions here - either use something that is so well studied
and widely used, that the vulns have been already fixed, or at least, that there are so many other bikes to steal, the chance they steal yours is small, giving you time to fix the lock.
i.e. just use tls.

and the other strong position is making something so simple that it's obviously secure.

I think the possibility for simplicity is considerable here, given that, ipfs, etc, doesn't rely on the security of the connection for it's security. the data is already secure, and it' would still be secure
over plain text - we are only encrypting it to prevent passive eavesdroppers. maybe to authenticate
who we are talking to - but ideally, that could be done inside the privacy layer.

[Bren2010]

@dominictarr Because TLS is designed for a server-client model and heavily utilizes CAs--both of which are contrary to IPFS' design. There's also the point that TLS is incredibly complicated and has a lot of legacy to it, which makes it hard to re-implement securely in situations where we don't have access to standard TLS libraries.

The protocol is already as simple as possible while still satisfying the requirements placed upon it. (Those requirements being forward secrecy, mutual authentication, confidentiality & integrity of data, in addition to being extensible.)

Edit: I realized there was a point I could address. The reason it's better to build a secure channel is largely because of the mutual authentication. Before I wrote this, that's all that was being done--you authenticate each other and then you go back to communicating in plaintext.

That scheme achieves its objective in the presence of malicious actors inside the network, but it doesn't do anything to deter active adversaries (outside the network). So you come to the point that all the hard bits are done--it's incredibly cheap to just build the rest of the secure channel and then I get the guarantee that if I contact Alice, I know that everything I read is legitimately from Alice.

[whyrusleeping]

I agree that we should keep the protocol as simple as possible to allow it to be easily audited and understood. TLS is great, but has way too much baggage for what were after

[dominictarr]

okay to be honest, I am not well versed on exactly how complicated tls is, I can imagine it's more complicated than this, though, sure. But I just feel that this could be even simpler.

There are really two distinct things here - privacy and security. ipfs is secure even over plain text,
because it's an authenticated data-structure. likewise, git (if you sign tags), bittorrent, secure-scuttlebutt. The other thing is privacy.

If you just did privacy, and required the application/next layer to handle authentication and integrity then you could simplify this.

And if you had an out of channel way of setting the parameters then you would not need cipher suite negotiation you could just put {hash, ip, port, ciphersuite} tuples into the dht... and then when you upgrade the ciphersuite, switch to the new port. This would allow a rolling upgrade, and mean there are very few edge cases in the private-channel.

[Bren2010]

okay to be honest, I am not well versed on exactly how complicated tls is, I can imagine it's more complicated than this, though, sure. But I just feel that this could be even simpler.

Reverse engineering someone's TLS implementation is a multi-week effort (I've done it). This protocol took me a few hours to design and implement. It took a few minutes to figure out how it worked after I'd been away from the codebase for a while. This is only a few hundred lines, whereas TLS implementations are thousands of lines.

Personally, I think it's incredibly easy to reason about the security of this, and I would think you do too since you started finding caveats within minutes of being told where the code was.

There are really two distinct things here - privacy and security.

I don't know what either of those words mean in this context... I'm guessing confidentiality and integrity? If so, as I said, confidentiality was added for the reason "why not?" and integrity is there so that I know everything I read off of my channel with Alice was actually written by Alice and meant for me--remember, there'll be more going through our channel than items from the DAGStore. Information about Alice's health, what she wants, what she knows.

And if you had an out of channel way of setting the parameters then you would not need cipher suite negotiation you could just put {hash, ip, port, ciphersuite} tuples into the dht

Disregarding the fact that the logic is circular and that this doesn't add anything, how is putting information into an incredibly complex system of computers simpler than just sending it over the wire to people who ask?

[dominictarr]

Okay good point, this is relatively simple.

But, I think you should consider the out-of-band ciphersuit thing.
In particular - it makes it much easier to upgrade the protocol -
this is a very important aspect of ipfs, if it works out, it's expected to be used for a long time.
Decades is reasonable, there are lots of protocols that old in use today.

Sure, you could negotiate a different suite, but you can't remove the negotiation,
so it's always gonna leak some information, but if the protocol/ciphersuit is distributed another way...
you could have an even simpler protocol than this, and you could have neat things,
like have the connection appear completely random from the first byte.

In a p2p system like ipfs, there is already a lookup to go from a peer id (i.e. hash(pubkey))
to a (possibly temporary) peer address, adding the suit/protocol to that is not much extra effort.

[jbenet]

@dominictarr

So like this:

# current multiaddr
/ip4/10.20.30.40/tcp/1234/ipfs/QmZSWmvJdrjtUo9TAVnRnRZbMfgcVbMbwMBhvsYTjBZ9es

# multiaddr specifying tls cypher
# 0xcc14 = TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
/ip4/10.20.30.40/tcp/1234/tls/cc14/ipfs/QmZSWmvJdrjtUo9TAVnRnRZbMfgcVbMbwMBhvsYTjBZ9es/

# some future
/ip8/QmZSWmvJdrjtUo9TAVnRn/sc/cc14/ipfs/QmZSWmvJdrjtUo9TAVnRnRZbMfgcVbMbwMBhvsYTjBZ9es/

[Bren2010]

But, I think you should consider the out-of-band ciphersuit thing.
In particular - it makes it much easier to upgrade the protocol -

@dominictarr The protocol is already trivial to upgrade.

Want to add a new cipher? Implement it and add it to the supported ciphers list.
Want to upgrade the protocol with major breaking changes? Create a supported versions list and negotiate which protocol version to use.

You never remove negotiation because there is always a need to negotiate something. TLS (even dating back to SSL) has never changed the ClientHello and SeverHello messages because there's no reason to.

so it's always gonna leak some information, but if the protocol/ciphersuit is distributed another way...
you could have an even simpler protocol than this, and you could have neat things,
like have the connection appear completely random from the first byte.

The protocol is always going to be trivially distinguishable from random. There's structure to the timing of messages in the protocol. There's structure in the objects sent. IPFS nodes will always behave in predictable ways (unless @jbenet decides to recast the project as a DRBG).

If I look up someone's preferences in the DHT, I can calculate the suite we should use because I have both variables, but how do I convey that knowledge to them if my only way of talking to them is walking up and just using the suite? Negotiation is a function of two variables, so how does the person on the other end make that calculation if they don't know anything about me?

In a p2p system like ipfs, there is already a lookup to go from a peer id (i.e. hash(pubkey))

If you're new to the network or have limited connectivity, how do you find someone's preferences to make a new connection to them to improve connectivity? How do you avoid the circular dependency of "I want to talk to Alice, so I need to look her up in the DHT, and that requires making a connection to someone, so I look them up in the DHT, which requires making a connection to someone, so I look..."

[whyrusleeping]

I do agree that all the information in the handshake should be available in the DHT for lookup, but i do also think it needs to be in the handshake for the very same reasons @Bren2010 expressed in his last paragraph.

[dominictarr]

So, i think the world has changed a lot since tls was conceived. The most important thing is how updates occur - I remember getting netscape navigator on a CDROM from my isp. Of course, you are not gonna get an update out very quick that way, and some people will never upgrade.

Nowadays we have automatic updates - sure, that is back door, but lets say we can create a decentralized way to do something like that (I have ideas, we can discuss later) I don't think we have the same concern for legacy code with ipfs, etc. But also - http has a default port, and surfers follow links to your site, and you can't break links or you break the web. web protocols had to be on the same port.

Ipfs does not have links that will break like this - because links are to data, not to servers.

How does a new peer find the network? A completely new node still needs an entry point, right?
This means something like a "start list" of servers that tend to stay online and addressable. This doesn't centralize the protocol because they are still regular nodes, and anyone can start a startlist node - it's just a matter of publishing it's address widely.

If we need to keep the start list servers accessable, that start list could contain the cipher suite, or it could indicate that a negotiation handshake is used instead. Is this how ipfs will introduce nodes?

[jbenet]

Ipfs does not have links that will break like this - because links are to data, not to servers.

Exactly.

How does a new peer find the network? A completely new node still needs an entry point, right?
This means something like a "start list" of servers that tend to stay online and addressable. This doesn't centralize the protocol because they are still regular nodes, and anyone can start a startlist node - it's just a matter of publishing it's address widely.

Yes, we use a list of bootstrapping addresses, which include the node.ID (public key). e.g.

/ip4/104.131.131.82/tcp/4001/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ
/ip4/1.2.3.4/udp/5234/QmSPS2WsvjFJ7AsTULbxw4o7oGD2PVTkR9zbiWQcapCtzS
...

Note that all distributed systems have the bootstrapping problem and solve it effectively the same way. DHTs, bitcoin, even DNS (hard coded root . resolver IPs).

For our purposes, we'll distribute signed, up-to-date bootstrapping list with implementations, and make it available via HTTP, DNS, and other systems.

If we need to keep the start list servers accessable, that start list could contain the cipher suite, or it could indicate that a negotiation handshake is used instead. Is this how ipfs will introduce nodes?

Yeah, we could do something like:

/ip4/104.131.131.82/tcp/4001/tls/cc14/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ
...

but i'm not yet convinced negotiation of cyphers is a bad idea. nodes should be more stern about the cyphers it uses (i.e. prune out weaker things) (NB: not negotiating cyphers does not get rid of handshake. would have to get rid of ephemeral sec chan key to do so. which we could do, since trust here depends on the source key. sessions strictly live shorter than the key used for node.ID (i.e. does forward secrecy make sense if the master private key which defines the node is compromised??) . AFAICT right now, the only other benefit of the ephemeral key is letting nodes split up implementations and safeguard keys better (i.e. i could have a full implementation that i don't give my private key to, only derived keys).

[whyrusleeping]

would be kinda cool to have udp service discovery implemented for ipfs

[jbenet]

would be kinda cool to have udp service discovery implemented for ipfs

yep!! there;s lots of protocols for local discovery, we should use as many as we can. this helps bittorrent clients be so successful at moving data around.