Unsurprisingly, I support adoption of draft-bittau-tcpinc-tcpcrypt-04. Tcpcrypt is simple, relatively self-contained, and custom tailored to the goals of the TCPINC working group. It has no external dependencies that could block progress. Tcpcrypt is also well suited for implementation in TCP stacks, where one doesn't always have access to the usual set of system libraries. Furthermore, I believe it is a huge advantage for TCPINC to have full change control of the protocol. Tcpcrypt has already undergone multiple changes in response to the working group. Once it is adopted, we will have full freedom to address any further concerns in the simplest way possible.
I also believe there's value in having protocol diversity, so we don't put all our eggs in one basket. I like the fact that when a vulnerability is discovered in an SSL implementation, I can SSH to my server to upgrade my library. Because SSH doesn't use SSL, at least my SSH connection isn't susceptible to the same problem. Of course SSH, too, may have problems, but I can guard against those with OpenVPN. So the world is clearly better off for having both SSL and SSH, and I see tcpcrypt becoming a valuable third tool in our arsenal. David _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
