IPFS doesn't use TLS

[willglynn]

protocol/network#Encryption:

IPFS uses cyphersuites like TLS.

NOTE: we do not use TLS directly, because we do not want the CA system baggage. Most TLS implementations are very big. Since the IPFS model begins with keys, IPFS only needs to apply ciphers. This is a minimal portion of the whole TLS standard.

So you rolled your own transport encryption? I find this surprising, and I'm… skeptical.

This needs to be a new section (or an entirely separate document) rather than an aside.

(Also, I'll add that if all you want is to connect to something, exchange RSA public keys, and get an encrypted transport stream, TLS is entirely capable of providing that without involving CAs.)

[willglynn]

I flipped through the IPFS crypto code and didn't see anything screaming out as obviously wrong. I am curious about the choice of HMAC + stream ciphers over AEADs, and again I don't even remotely understand why TLS won't work here instead.

That said, I was trying only to figure out how IPFS encryption works in absence of documentation, and I am not an expert in this field. Some people who know more about crypto than I do say things like:

In the 1990's it was common for cryptographers to produce block ciphers and hash functions, and then developers would be tasked with composing them. In the talk I stepped through the design of, and attacks on, the SSLv3/TLS CBC construction as a demonstration that plausible-sounding design features can lead to disaster, but I'm going to omit that here because it worked better live. (Phillip Rogaway tried to warn about these issues when SSL, IPSec, etc were being developed, but sadly the right people didn't listen to him.)

So, for quite a long time now, cryptographers have understood that block ciphers and hash functions are too low-level an abstraction and that the constructions themselves need to be studied and standardised. The result is called authenticated encryption (AE)

– Adam Langley, author of much of Go crypto/*, in a recent blog post about AEADs

The point here is that the best security methods leverage the collective analytical ability of the cryptographic community. No single company (outside the military) has the financial resources necessary to evaluate a new cryptographic algorithm or shake the design flaws out of a complex protocol. The same holds true in cryptographic libraries. If you write your own, you will probably make mistakes. If you use one that's public and has been around for a while, some of the mistakes will have been found and corrected.

It's hard enough making strong cryptography work in a new system; it's just plain lunacy to use new cryptography when viable, long-studied alternatives exist. Yet most security companies, and even otherwise smart and sensible people, exhibit acute neophilia and are easily blinded by shiny new pieces of cryptography.

…

This doesn't mean that everything new is lousy. What it does mean is that everything new is suspect.

– Bruce Schneier in Cryptography: The Importance of Not Being Different from 1999

Anyone can invent a security system that he himself cannot break. I've said this so often that Cory Doctorow has named it "Schneier's Law": When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.

– Bruce Schneier again, as an aside in a 2006 Crypto-Gram

So: what makes TLS unsuitable for use in IPFS? Does that same rationale also apply to DTLS, SSH, and every other pre-existing transport encryption scheme? Why invent your own?

[jbenet]

( i wrote this before your second post )

We may use CurveCP. TLS 1.3 is also shaping up nicely, we may use it. And we may also just go for QUIC (inc DTLS).

So you rolled your own transport encryption? I find this surprising, and I'm… skeptical.

Why? I understand the dangers perfectly. But TLS is no pancea. Its implementations have been, for a long time, a bag of disasters. And the model is so lose-- easy to do something wrong with all the options. I actually found it easier to review one (AEAD-like) protocol that we can audit clearly, is written in Go (safer than C, much easier to audit), using primitives in the stdlib written by AGL.

In short, "crypto is hard" but that does not mean "never design new protocols". It means "label your protocols insecure until a strong part of the security community is confident in its design AND implementation". Otherwise, we'd be stuck forever :). (FWIW, TLS 1.3 and DTLS came out of orgs like Google making the same call).

To be clear, we label our stuff "insecure" until we have audited it professionally and exposed it to many other strong crypto engineers. So far, all of our networking stack is, under this definition, "insecure". Though as far as we know, it has stronger security guarantees already than many other p2p systems branded as secure (tl;dr: we have high standards)

This needs to be a new section (or an entirely separate document) rather than an aside.

Time. PRs accepted.

if all you want is to connect to something, exchange RSA public keys, and get an encrypted transport stream, TLS is entirely capable of providing that without involving CAs.

Most libraries I've seen require certs, or do not make it clear how to do it without, safely.

And no, not just RSA keys. people will be able to choose ed25519 keys soon enough, and maybe others later. Two peers, one using RSA and another using ed25519 should be able to talk. I don't recall whether TLS permits this (my guess is not, but i don't have nice docs atm (am offline)).

---

In any case, i'm all for being more secure with less work, just TLS has a ton of baggage i'd really like to end. CurveCP is a more attractive choice. But it makes other decisions too... DTLS is good when using QUIC ....

[jbenet]

I would add that if TLS can be used without all the X.509 nonsense, and with our own choice of pubkeys, including using different signing public keys (not the DHE keys) in the same conn, then we can consider breaking our "not TLS pls" stance.

[willglynn]

This needs to be a new section (or an entirely separate document) rather than an aside.

Time. PRs accepted.

I can see the code, so I can piece together an understanding of the current protocol. I was hoping to find a document to describe why it is what it is – what problem the IPFS encrypted transport layer needs to solve – in order to better understand it. This discussion is a good starting point.

Why? I understand the dangers perfectly. But TLS is no pancea. Its implementations have been, for a long time, a bag of disasters.

Maybe so, but applied crypto on the whole has been a bag of disasters, and there's a lot more people working on/near TLS (both protocols and implementations) than not. Staying near the crowd in general and using TLS in particular offers advantages.

And the model is so lose-- easy to do something wrong with all the options.

It seems even easier to do something wrong starting from scratch.

In short, "crypto is hard" but that does not mean "never design new protocols".

Agreed, there is a place for new protocols. I don't know exactly what problems this component is trying to solve, so I'm not sure this is one of them.

TLS is an existing protocol that offers an encrypted transport with mutual identity verification. Maybe IPFS genuinely needs something different, in which case a new protocol makes sense, but if not, I'll defer to Schneier:

it's just plain lunacy to use new cryptography when viable, long-studied alternatives exist

If TLS is viable, IPFS should use it.

It means "label your protocols insecure until a strong part of the security community is confident in its design AND implementation". Otherwise, we'd be stuck forever :)

I appreciate the labeling :-)

if all you want is to connect to something, exchange RSA public keys, and get an encrypted transport stream, TLS is entirely capable of providing that without involving CAs.

Most libraries I've seen require certs, or do not make it clear how to do it without, safely.
…
I would add that if TLS can be used without all the X.509 nonsense

Yes, TLS uses certificates for this purpose – certificates encoded in X.509 at that. This does not require that any CA is involved.

Certificates are a pre-existing way of linking identity with public keys, and presenting a certificate in a TLS handshake is a pre-existing way to assert that identity. I would favor their use for this purpose, even if the IPFS concept of identity is currently just "this is my key".

As for X.509, I've found that people often have a distaste for X.509 because of ASN.1, which can be charitably described as being flexible in all the wrong ways. However, the IPFS protocol as implemented today uses ASN.1 to encode RSA keys for transport, so ASN.1 must not be the dealbreaker. In fact, the IPFS protocol encodes public keys into an X.509 SubjectPublicKeyInfo structure right now. All that would be needed to make it an X.509 Certificate is to wrap that SubjectPublicKeyInfo in a TBSCertificate, fill in some fields with sensible defaults, and sign the result.

Further, even if X.509 were categorically rejected, that would still not rule out using TLS. One can use arbitrary cryptographic identifiers in place of X.509 certificates (e.g. PGP keys) – just identify them appropriately.

And no, not just RSA keys. people will be able to choose ed25519 keys soon enough, and maybe others later.

Good to know.

Two peers, one using RSA and another using ed25519 should be able to talk. I don't recall whether TLS permits this (my guess is not, but i don't have nice docs atm (am offline)).

Both parties need to understand and use the other's algorithm, but yes, TLS permits this. (Also, ed25519 in TLS is pre-standard.) Servers prove themselves to clients in one of two ways:

• In an RSA key exchange, the client generates a premaster secret and encrypts it with the server's public key, which the server then decrypts with its private key.
• In a DH key exchange, the sever generates DH parameters and signs them with its private key, which the client then verifies using the server's public key.

In either case, TLS key exchange employs the server's keypair and associated algorithm.

Clients wishing to assert their identity send a Certificate message followed by a CertificateVerify message. (Presumably this would be a requirement for IPFS, but it's optional for TLS on the whole.) CertificateVerify is signed with the client's private key, which the server then verifies using the client's public key. This is separate from the key exchange process, and it need not use the same algorithm, so long as both parties find it agreeable.

[jbenet]

You're right in many counts. a few notes:

• we'll be changing the format for keys, we'll be using our own, self describing wrapper format (like multihash). but yes, we'll allow ASN.1 as we'll have to for compatibility.
• the X.509 stuff is just way too complicated for most of IPFS use case. as i mentioned, we originally intended to work on a secure channel implementation and submit it to the crypto community to be analyzed. but agree with you though that until that happens, we should use something well-vetted.

How about this as a path forward:

• we define our key format, etc. (we also want to allow users to provide their own keys, like pgp keys)
• we figure out our PKI things -- see the very, very early https://github.com/ipfs/specs/tree/master/keychain thing we're making. (basically content addressed PKI with all the crypto artifacts floating in IPFS)
• we figure out how to make this work nicely with TLS
• we switch from this thing to TLS/TCP instead.

Another thing left to figure out:

• should the encrypted channel be part of a multiaddr, or just be selectable via multistream.
  • argument for multiaddr: different transports will obviate some, like QUIC includes DTLS, CurveCP includes reliability. /ip4/1.2.3.4/udp/1234/quic and /ip4/1.2.3.4/udp/1234/curvecp))
  • argument for multiaddr: can inspect the address and discard all addrs without an encryption channel, or those that use undesired encryption channels. (allowing nodes to not even connect to old, unsupported nodes)
  • argument for multistream: allows different encrypted transports to be used over one transport without an additional multiaddr. (could still do this with multiaddr by specifiying multiauth as a placeholder multiaddr protocol or something, e.g. /ip4/1.2.3.4/tcp/1234/multiauth could provide TLS and some other protocol).

[jbenet]

cc @diasdavid

[jbenet]

Hey @willglynn -- would you be willing to help us out with some of this? would be good to move towards (perceived-to-be-)safer crypto.

I think we should add TLS and CurveCP to https://github.com/ipfs/go-libp2p as Transports

I think we should add TLS and CurveCP to https://github.com/ipfs/go-libp2p as Transports

Would that be transport-over-transport? I imagine we wouldn't neccessarily do it over TCP in the future. At least for cjdns' CryptoAuth, it could be e.g. TCP-over-CryptoAuth-over-UDP or QUIC-over-CryptoAuth-over-Ethernet.

[jbenet]

Would that be transport-over-transport? I imagine we wouldn't neccessarily do it over TCP in the future.

TCP is just one more transport, so layerings would look like:

/tcp/secio/<muxer> -- today
/tcp/tls/<muxer>
/curvecp/<muxer> -- secure, reliable
/quic -- secure, reliable, muxer

cjdns/CryptoAuth is secure, does it give either {reliable, muxing} ?

layerings would look like

We should work on getting that into multiaddr very soon! Together with /dns support! Saying this because they both require relaxing the current /key/value/key/value scheme.

cjdns/CryptoAuth is secure, does it give either {reliable, muxing} ?

CryptoAuth only gives you an unreliable channel per-peer. Reliability and muxing are done by TCP in the kernel (TUN/TAP interface). What would an unreliable channel be called, btw? It's just packets, not a stream. Maybe you can point me to something that clears these terms up, in our context.

[ekr]

Your two objections to TLS seem to be the tie to the PKI and the typical size of stacks. In that case, you might be interested in the folliwing:

• RFC 7250 permits raw keys instead of certs with TLS
• Mint (https://github.com/bifurcation/mint) is a lightweight TLS 1.3-only stack written in Go but matching the GoLang TLS API. It doesn't support RFC 7250 but easily could be made to, I suspect.

[Edited to remove misattribution of the original objections]

[jbenet]

@ekr thank you for pointer to mint. we'll be revisiting this soon and adding TLS to go-libp2p as an auth transport so IPFS can use it.