An absence of a canonical order or a definition of a well-formed packet sequence is itself a flaw in the packet format. Other cryptographic serialization and encoding schemes do not make this mistake.

I wrote the "PGP Problem" article and definitely was not just talking about "the format of individual packets", which you might be able to tell from the fact that it brings up a quadratic parsing DoS in that design as well.

That's not the argument, it's that it's a bad design repeatedly shown to be shown to be prone to serious vulnerabilities and it's silly to argue it's not a bad design at yet another such time.

People have made serious arguments for all sorts of design problems in SSL/TLS.

Completely agreed!

The basic thesis of that post (the original of which I wrote) is that if messages are important enough that they need to be protected from state-level adversaries, then they're important enough that you shouldn't care about all the other reasons you like SMTP. If any of SMTP's affordances trump message security, you're LARPing the security part: you're protecting them in a threat model that doesn't correspond to a real-world attacker.

With email, you necessarily leak the triple (to, from, date): no matter how good your cryptosystem is, that information can be pulled from the mailserver logs (and if you don't leak that triple, spam deluge is unsolvable). As a practical matter, you generally need to leak the mail headers as well, which contains a decent amount of useful metadata as well. Now I'm not an expert on how spy agencies do their analysis, but my understanding is that the set of information that has to be leaked by email is already the most useful information for them. And that's part of tptacek's point: if your main threat adversary is state-level actors, you've already lost if you're using email simply because you're using email.

What if your threat model isn't state-level actors? Well, the baseline of email these days is that your communication and your recipient's communication to the mail servers are both encrypted with TLS. The mail servers themselves may or may not communicate with each other using TLS, but if you really care about security, you can choose a mail server which will be using TLS. In other words, email is already at a baseline state of the only people aware of the message being the sender, the recipient, and their mail admins (and whomever these people choose to leak the message to, perhaps unwillingly). Encrypting email will only remove the mail admins from the list, and even then, they can still tell anybody whom you talked about.

So the use case of encrypted email boils down to wanting to hide the contents of communication but not hiding the fact of communication itself. Which isn't a broad use case; the best examples I've found in my own life is something like financial statements, but even in those cases, there's a pretty decent workaround: send an email saying "hi, we have a document for you online in our usual secure file repository" (protected by modern, useful standards for secure files). I don't like that only because I can't automate saving those files off to my own storage for my own purposes, but that is such a niche desire that I can understand why the bank doesn't bother.