> The track-record of actual TLS implementations in practice should also > not be disregarded; the reality seems to be that very general high > security cryptographic protocols may be at the edge of or beyond the > internet communities current collective engineering ability; The > narrower scope and purpose of tcpcrypt vastly simplifies both protocol > and implementation review, even though it may somewhat increases the > total number of security critical lines of code to be reviewed (though > even that isn't clear.).
Code audit seems a really valid argument. Yet, from a TCP perspective, I'd come to a quite different conclusion regarding what this implies to the TCPINC design. Unless I miss something, the difference between tcpcrypt and a solution running in the TCP payload (again, to me a TLV design does not have to be TLS) is that the tcpcrypt code audit has to analyze the complete TCP stack, whereas in case of a TLV protocol in the payload the code review just comes down to reviewing a narrow-scoped (kernel-internal or kernel-external) library handling the encryption on top of the existing, security-hardened TCP byte stream transport. Production TCP stacks are very complex. As a result, my impression is that only a rather small number of developers and IETF contributors completely understand a state-of-the-art TCP implementation, in particular in corner cases that attackers would probably try to leverage. Adding a significant number of new, non-trivial features in the core of the TCP stack could have side effects that are extremely hard to detect even by TCP experts. The more features we add inside TCP, the higher the risk that we actually add *new* security bugs to all TCP-based communication, even for connections not using TCPINC. I have no own expertise with security reviews of code. But I imagine that reviewing a library that is separated from the complex TCP protocol engine (e.g., its SACK implementation) should be simpler to many people familiar with security reviews. In particular, a reviewer would probably not have to be an expert for all segment handling aspects inside TCP, including the many non-trivial corner cases. In summary, I believe that for security reviews a TCPINC design running on top of the TCP byte stream should be much simpler than the current typcrypt design. What do I miss? Thanks Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
