Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

Parent Full thread

I agree with the massive increase in complexity brought on by newer versions of HTTP and the attempt at essentially reimplementing TCP over UDP, but I think a binary protocol will be much simpler and more efficient than a text one.

Eliminate ambiguity (and several classes of exploits):

It's easier to "start small" (i.e. with a short binary encoding) that won't be much ambiguous in the first place, than to try to add restrictions (and thus additional complexity) to a freeform text protocol. Or put another way, instead of adding error cases, it's better when there are no error cases in the first place.

Encode certificates with human-readable JSON instead of ASN.1 DER.

Hell no. DER is prefix length-delimited, JSON (and text in general) is not.

This means that unmaintained software will stop working after 2 years.

Hell fucking no! The last thing that anyone who cares about things working wants is planned obolescence and even more constant churn (which just leads to more and more bugs.) If anything, that will only make the "handful of implementations" of TLS turn into perhaps one (i.e. Google's), or maybe two at most. Thats even worse.

Replace TLS. It is mind-numbingly complex.

Replace it with what? Your proposal essentially reinvents the main pieces of TLS (authentication, confidentiality), and TLS is already quite modular with respect to that.

Have you tried to write an X.509 DER PEM file parser? I started one. Just reading the specs (X.509, ASN.1, DER, & PEM) takes two days. If writing a JSON parser is a walk down the block, then writing an X.509 cert parser is a marathon.

How is TLS modular? It mixes encrypted and unencrypted message types [0], leading to implementation vulnerabilities [1]. It contains many unused and unnecessary features and extensions, some of which are very bad ideas (renegotiation, client_certificate_url). We all deserve a good protocol to protect our data and systems. The complexity of TLS helps the incumbents, stifles innovation, and harms privacy and security.

Many organizations spend a lot of money and effort to upgrade software and prevent obsolete software from running. This will become a bigger need in the future as ransomware attacks become more common. Building mandatory upgrades into an Internet protocol would take boldness and courage. The benefits will accrue to everyone in society: Less of our data will get stolen by criminals and spies. Fewer organizations will get extorted by criminals. Fewer hospitals will get shut down.

[0] https://tools.ietf.org/html/rfc8446#section-5

[1] https://mitls.org/pages/attacks/SMACK

PEM is not DER, it's base64'd DER, and not necessary to implement TLS (which only uses DER for X509.) I haven't written any code for it, but I've debugged some, and read the spec and hexdumps, and I'd much rather work with DER than JSON. Everything length-prefixed, no "keep reading until you find the end" horrors. JSON is simple on the surface, complex on the inside; ASN.1 is somewhat like the opposite of that. You may find this article enlightening: https://news.ycombinator.com/item?id=20724672

The complexity of TLS helps the incumbents, stifles innovation, and harms privacy and security.

...and your "solution" to replace it with something that churns even more insanely frequently won't "helps the incumbents"? We already have the horrible Chrome/ium monopoly situation as evidence. I've just about had it with the fucking "innovation", I want stability.

The benefits will accrue to everyone in society: Less of our data will get stolen by criminals and spies. Fewer organizations will get extorted by criminals. Fewer hospitals will get shut down.

Every utopian vision turns into a dystopia. That "think of the security!" doublespeak grandstanding is becoming disturbingly Google-ish.

I'm done here --- clearly you can't be convinced (or are deliberately trolling), and neither can I.

I did not intend for you to become frustrated. I am being earnest.

Most software systems change only by adding complexity and features. This is because owners rarely have the courage to break any users' stuff. This is OK for a growing company since they earn more money as they add complexity. But it's counter-productive for security. Security depends on simplicity.

Evolving systems means adding support for new things. To evolve systems and maintain simplicity, we must also remove support for old things.

Dropping support for a feature is currently a political ordeal. Folks maintaining old systems don't want to upgrade them to use the new thing. So they push back against the drop. Regular dropping will force these organizations to adopt regular upgrade processes. With regular dropping, protocol/library/language maintainers can drop features without incurring much extra work for users. This will let them get rid of technical debt and iterate much faster, increasing the rate of innovation.

New features get introduced, and old features slowly get dropped as they cease to be used. All seems fine.

> Have you tried to write an X.509 DER PEM file parser? I started one. Just reading the specs (X.509, ASN.1, DER, & PEM) takes two days. If writing a JSON parser is a walk down the block, then writing an X.509 cert parser is a marathon.

I have. It wasn't particularly difficult. Yes the specs took about two days to get my head around but that's not a large amount of time. I certainly wouldn't describe it as a marathon.

> Hell no. DER is prefix length-delimited, JSON (and text in general) is not.

This is a bit disingenuous, Content-Length header is required, or defacto required, and every http 1.1 server out there has a reasonable maximum allowed request header size.

Reply on news.ycombinator.com