Most (not all) of what's gone wrong with TLS has gone wrong in things that had already been outmoded for a very long time, and long since replaced with better constructions in later versions of the protocol.
Most (not all) of what's gone wrong with TLS has gone wrong in things that had already been outmoded for a very long time, and long since replaced with better constructions in later versions of the protocol.
There is so much accumulated cruft to SSL/TLS and the implemented x509 certificate scheme that to me, as a noob who knows nothing about crypto i.e. the average user, the easier path is to scrap all that ("shed all legacy" junk) and focus on learning a few things that are both flexible and known to be useful. I believe NaCl fits this role.
I have some basic UNIX-like utilities built with NaCl, one for each function (crypto_box, crypto_secretbox, etc.). Minimal non-djb code. In the interests of experimentation and learning, I prefer using small, separate utilities versus applications that do multiple jobs.
I would be interested in an "expert" opinion on my experiments with these utilities but crypto is such a devisive topic. Though they may be initiated as sensible, honest questions, online discussions quickly turn toward dogma supporting status quo, mindless memes, subtle insults and are sometimes derailed into the realm of absurdity. I would post an example of the usage for comment, but I am not interested in being chastised by the HN peanut gallery. It is just intellectual experimentation, nothing more.
IMO, as a general principle not limited to crypto, there is nothing wrong with "custom" anything if it has passed the same QA tests as the "mass-produced" version. Sometimes in fact custom is higher quality than mass-produced. Popularity does not always signify higher quality. Perhaps nowhere is this more evident than in the world of software.
IMO, a "naclwrap" program would be very useful, even in a "TLS world". Like stunnel but for nacl. Whether "everyone" would use it is an interesting question but ultimately not something I care about.
But, again, you can remove 80-90% of it if you don't care about compat. People run into a cognitive block when they think about TLS because they assume TLS means "browser compatible". But no browser speaks a NaCL transport today, so that's out the window.
Without the requirement to support browsers, you can:
* Allow only an ECDH handshake.
* Allow only the Chapoly ciphersuite, in TLS 1.2's AEAD format.
* Eliminate CAs and do an SSH-style key-continuity scheme.
This TLS "subprotocol" already exists and is already supported by most of the TLS libraries, all of which have been audited. It's supported by middleboxes and monitoring tools so it can be deployed operationally. Every mainstream programming language has bindings to it. Meanwhile, NaCL doesn't actually provide a transport protocol or even the security semantics of a secure transport; that's work you'll have to do de novo, and you will generate bugs doing it.
So what's the advantage to scrapping TLS and redoing it with NaCL?
But unlike you I have little interest in "browsers". This is why I would want a "naclwrap" utility but you might not see any point. CurveCP is the experimental transport protocol. I do not need it in a browser because I am not interested in browsers. I like experimenting outside of browsers and the "web" so I have no reason to resist CurveCP.
What is the advantage of scraping TLS? If you mean for everyone, maybe there is none. Why not allow both TLS and NaCl to coexist? Why does TLS have to be "redone" with NaCl?
For me personally, the advantage of "scraping TLS" is that I get to ignore all the cruft and complexity that I have to sift through to get to the proper "subprotocol" within TLS. Too much work.
I am not the one who will write "naclwrap" if it ever is released. The person who wrote it does not introduce bugs and security issues. He is not like the people who work on TLS and most developers in general. He is careful.
In any case, I am not tasked with persuading anyone else to scrap TLS. I am simply a user who 1. likes NaCl, 2. prefers the idea of per packet encryption to the notion of encrypted "tunnels" and 3. is apt to complain about TLS only because like other web users I am forced to use it whether I want to or not.
For someone focused on influencing developers who write programs for other people, shaping web standards or at least very interested in where they might be heading, your comments are poignant. But I am just a user. I write trivial programs for myself. I am not futilely trying to tell developers what to do, shape standards nor am I very interested in where things are heading, except to the extent I can minimize the computer usage-related annoyances I must endure.
As for OpenSSL, not everyone is on 1.1 yet. There is no ChaCha20-Poly1305 in 1.0.1_. So while some bits of NaCl have been adopted into the TLS suite, it is only a subset of web servers that are supporting the so-called "subprotocol". And still no Ed25519, even though it has been used in OpenSSH for some time now.
All these factors make TLS undesirable for me. Too much complexity compared to NaCl, IMO. For others, TLS may be the right choice.