In my view one of the most significant advances of TCPCrypt is setting appropriate layering.

Past cryptographic network transports have committed the sin of layer violation by conflating stream management with correspondent authentication. Authenticating that you are talking to whom you think you're talking to is a complex, highly application specific process which in many cases even requires its own UI.

The code to implement authentication is complex and has (e.g. x509 parsing) frequently been a source of vulnerabilities, making it unattractive for implementation in network stacks. Witness the use of TLS for non-webby applications where there aren't readily user provided domain names and things don't fit nicely into a one-side-authenticated server/client model-- they often turn into key management nightmares.

TCPcrypt handles the stream encryption and integrity in the network layer where it can do so seamlessly. It hands up the stack the required hooks so that authentication can be performed in whatever way makes sense for the application. As a bonus, even when authentication isn't used applications are protected against dragnet passive content surveillance.

WireGuard authenticates traffic, using modern constructions, and its kernel implementation is famously fewer than 5000 lines of code, and can be implemented without dynamic allocation. Just because TLS is complicated doesn't mean that cryptographic authentication is fundamentally difficult. Watson Ladd once said, on the CFRG mailing list, that if TLS 1.1 had been turned in as an undergraduate assignment, it would have gotten a D. (I'm paraphrasing from memory).

> WireGuard authenticates traffic, using modern constructions

Assuming you know in advance of your connection a correct public key for the corespondent. How you got it, how you know it's correct is ... left up to you. Yet it isn't secure if its not done exactly right.

This is like arguing that a one time pad provides for unbreakable encryption. True in one sense, often not true in practice.

You conveniently ignored the 30k LOC crypto framework.

The thing is, you still need to validate the session id, if you want to know who you are talking to. And in order to do that, you probably need to do something like use x509 certs. And once you do that, you've basically re-arrived at the same layering issues that TLS has.

So, like, the protection against passive listeners is nice. But, what I don't understand is a specific example of where using tcpcrypt would be better than just using a widely used TLS library.

> This seems to primarily only protect against passive listeners [1].

Which is still useful in that it prevents organizations from simply 'tapping glass'.

I'll take the imperfect security of forcing various agencies to expend resources to go after me personally (which is a small chance of happening) versus the ease of them simply vacuuming up all the bits.

It's why I also think that unauthenticated encryption is useful even if it doesn't protect against active attacks: the extra resources needed for the active component forces the adversary to make choices on who to target.

> I'll take the imperfect security of forcing various agencies to expend resources to go after me personally (which is a small chance of happening) versus the ease of them simply vacuuming up all the bits.

On the one hand: protection against passive monitoring is a clear win. On the other hand, in my opinion, saying something like: "which is a small chance of happening" is kinda problematic: you don't need that security, and if some agency targeted you, like, maybe there is a minor chance of personal embarrassment. However, there are also people in the world that when they are targeted, they could face prison time or worse. And the people with the most to lose, are also the most likely to be targeted. So, IMO, it would be somewhat irresponsible to rely on tcpcrypt - it gives people that don't really need protection protection that they don't need, but leaves everyone that does out to dry.

The thing is - I just can't think of a use case where it makes sense. HTTP is often used with TLS - and TLS offers protection against active attackers. Many new protocols are based on HTTP - right or wrong, that generally means they get TLS with whatever library they use. DNS is moving toward DoT and DoH. SMTP has STARTTLS already which does the same thing. FTP has been replaced by SFTP / SCP. Telnet is replaced by SSH. Instant messaging protocols have built in security.

What protocol and who would actually benefit from this?

> What protocol and who would actually benefit from this?

All of them.

We could have encrypted HTTP back in 2000 if HTTP Upgrade had been more widely deployed:

* https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header

How much of the stuff that the NSA (and others) did that Snowden exposed could have been made impossible, or at least more difficult, if there was more encrypted traffic to deal with?

Sure, there wouldn't have been little padlock icons, and active attacks could still be done, but it wouldn't have been as much wholesale surveillance.

Instead, between 2000 and (say) 2016—when Let's Encrypt/ACME went live—we had selective encryption only for 'important' sites where people thought it worth the cost/hassle of getting a cert and going HTTPS.

Even now, there are plenty of legacy HTTP-only sites: why not have an Apache module available that does opportunistic encryption, even if the end-user doesn't get a padlock icon.

> What protocol and who would actually benefit from this?

The main promise IMO is providing transparent encryption to old applications and protocols that use TCP without their own encryption layer.

It is not possible to provide transparent authenticated encryption to everyone without some sort of CA system for IPs, but we should still provide the strongest privacy available by default, which is protection against passive eavesdropping.

That sounds like a reasonable goal, I'm just at a loss for what old applications or protocols will benefit. Many of those old applications get stuck running on old kernels which would prevent this type of change from helping them.