News for hackers. Stuff that matters.
Re:RFC 8548: Cryptographic Protection of TCP Streams (Tcpcrypt) by nullc on Thursday May 23, 2019 @09:20PM (#19997646)
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.

Re:RFC 8548: Cryptographic Protection of TCP Streams (Tcpcrypt) by tptacek on Thursday May 23, 2019 @10:41PM (#19998015)
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).
Re:RFC 8548: Cryptographic Protection of TCP Streams (Tcpcrypt) by nullc on Sunday May 26, 2019 @01:08PM (#20015976)
> 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.

Re:RFC 8548: Cryptographic Protection of TCP Streams (Tcpcrypt) by crest on Friday May 24, 2019 @09:36AM (#20001274)
You conveniently ignored the 30k LOC crypto framework.
Re:RFC 8548: Cryptographic Protection of TCP Streams (Tcpcrypt) by dagenix on Friday May 24, 2019 @01:27AM (#19998733)
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.