JRFC 32 - Split TLS into two protocols

[jbenet]

a warning to the wise

Do not do what is described below blindly. If you ever attempt to write a secure channel protocol, you will need to pass your final design, and then your protocol implementations, through many security and cryptography experts (djb) who should tear it apart for you. Not doing so is (probabilistically) dooming yourself and your users to communicating in the clear.

---

TLS is about two things

(this idea originates in ipfs, namely this PR and a few conversations with various contributors)

1. distributing and authenticating keys of two parties wishing to communicate (X.509).
2. given keys, establishing a secure communication channel between the two parties.

I claim TLS should really be a layering of two protocols handling each of these concerns. I'm sure some standard exists somewhere in the literature, but I have yet to find it. For now, i'll dump ideas here regarding this effort.

---

For my purposes, I only need 2. above, the establishing of a secure channel. Thus, I propose to rip out the (thankfully simplest) part of TLS into its own protocol. A few notes:

• for compatibility, keep the same cypher suite naming (IANA TLS codes)
• keep cypher suite negotiation handshake
• handshake optional, protocol can be initialized with specific keys and cypher suite choice, making every byte encrypted (note this requires out of band session key derivation for DHE)

[kmag]

It sounds like you want something kind of like Kerberos, where one server (AS) handles authentication, another handles cryptographic key generation/negotiation (KDC) and the other servers just worry about providing a service for you. In practice, the AS and KDC are the same server, but the protocol design allows separation.

These secret session cookies that we now use to persist web service authentication for 2 weeks are a poor man's Kerberos ticket. Security could be improved and session overhead reduced by using actual Kerberos tickets.

In my ideal world, we'd be using something like DNSSec to distribute public keys for a Kerberos AS within DNS, and browsers would understand a SPAKE2+ (on Edwards Elliptic Curves) for zero-knowledge proof with perfect forward secrecy of key negotiation in order to get a Kerberos Ticket-Granting-Ticket (TGT) from the AS with a 2 week lifetime. The browser would then use the TGT to get Kerberos service tickets from the KDC for the various web services within the domain. The symmetric keys within the service ticket would then be used to encrypt and authenticate an ECDH key agreement at the beginning of each TCP connection to a web service. This way (1) nothing outside your browser would ever see your password, the worst case if they managed to con a certificate authority or steal a certificate, and attacker would see the SPAKE2+ verifier and zero-knowledge proofs (2) only the AS would ever have the private key for the domain's public key, instead of all of these servers running all kinds of less well audited code (3) perfect forward secrecy both from SPAKE2+ and ECDH (4) session initialization would be lighter weight, not requiring any signature checking and (5) authentication logic would be moved out of the application layer, where it doesn't belong. In the case of unauthenticated web services, the AS would directly give you ephemeral ECDH public keys for each service.

[sesam]

For reference; SRP http://srp.stanford.edu/ is patent-free snoop-resistant secret-verification, useful for encrypted channel init. Nice if you don't trust X.509 CA:s. No browser supports it yet, but could probably handle this just like self-signed cert. http://stackoverflow.com/questions/2778629/tls-srp-in-browsers

[kmag]

Unfortunately, SRP is defined only for a 1024-bit modulus, which is too
small these days. There have been a few attempts to define SRP over
elliptic curves, but all of the attempts I'm aware of have been shown to
leak information about the key. Hence, my suggestion of an alternative
Augmented PAKE that supports elliptic curves. You could define your own
4096-bit modulus, but the world is moving away from cryptographic
operations over Z_p.

On a side note, I foolishly emailed the SRP authors back in 2003 asking
them why their modulus wasn't prime... it turns out there was a bug in the
Sun Java runtime BigInteger primality test. The authors very politely
mentioned the Java bug and offered to send me a proof of primality. The
primality test has since been fixed.
On Apr 17, 2015 7:30 PM, "Simon B." notifications@github.com wrote:

For reference; SRP http://srp.stanford.edu/ is patent-free
snoop-resistant secret-verification, useful for encrypted channel init.
Nice if you don't trust X.509 CA:s. Nearly(?) included in some popular open
sourced browser.

—
Reply to this email directly or view it on GitHub
#32 (comment).

[dominictarr]

hey I've been looking into this again. I suspect that the answer is to use something like this: http://curvecp.org/ if not that exactly.

I've also been investigating how the various secure channels work and summarizing them here:
https://github.com/ssbc/scuttlebot/wiki/secure-private-channels:-the-good,-the-bad,-and-the-ugly

[dominictarr]

so i wrote a paper explaining a good way to do this: http://dominictarr.github.io/secret-handshake-paper/shs.pdf
(it does not go into the key exchange part)
implementation: https://github.com/dominictarr/secret-handshake

[ChristopherA]

@jbenet @dominictarr I'd love to continue this conversation of a TLS 3.0, or a MVP secure stream protocol. I regularly get comments about even the hello being in the clear.

[jbenet]

@ChristopherA would love to as well.