Richard Barnes <r...@ipv.sx> writes: > I have a pretty strong preference for (a), the Rescorla draft. New code > is undesirable in security systems -- better to rely on a known, > battle-tested code base. So it seems like a no-brainer to use TLS as the > starting point and making the minimum set of changes needed.
There are two problems with this argument, though. First, as already pointed out, you can't just drop openssl into the kernel, so new code will have to be written anyway. Second, things that are easier to implement are easier to implement correctly. Even if TCP-use-TLS required 10x or even 100x the engineering effort/lines of code/chose your metric as tcpcrypt, it would likely be able to muster the necessary manpower (if people care), given how huge TLS is. More available engineering power can certainly be an advantage, but it doesn't always translate into better security. Tcpcrypt, by necessity given the size of our team, has been designed to minimize implementation effort (even more so given the verified implementation effort at Kestrel, which even if we don't complete it still informs the design). That places more design restrictions on us in terms of complexity. It's a bit like designing an aircraft where you face strict weight and balance requirements. If we add something to tcpcrypt that requires an extra 40 hours to implement, this is a huge deal for us. For TLS, that amount of engineering effort would be in the noise (again, if people cared). Those two design methodologies are likely to lead to different failure modes in tcpcrypt vs. TLS, which is why I think the diversity of tcpcrypt + TLS could help overall security. Now there's another thing I worry about, which is my "(if people care)" asides. How much is the TLS community willing to make TCPINC a priority? With TCP-use-TLS, there may be a non-trivial risk that TCPINC gets shelved until after the TLS1.3 effort is complete. If you look back to past TCPINC sessions, like Toronto (http://www.ietf.org/proceedings/90/slides/slides-90-tcpinc-0.pdf) and Dallas (http://www.ietf.org/proceedings/92/slides/slides-92-tcpinc-2.pdf), you see repeated claims that, compared to tcpcrypt, TLS-use-TCP is "Easy to specify and implement." Also that TCP-use-TLS is a "pretty obvious subsetting exercise." Well, a priori, one can argue that even though TCP-use-TLS may require more engineering effort in absolute terms than tcpcrypt, the delta between application-level TLS (required anyway) and transport-level TLS is smaller than the effort required for all of tcpcrypt (which can't be shared). However, a posteriori, given that we still don't have a profile and the (still proprietary) implementation took so long to realize, I think there's a good chance that either a) people underestimated the effort required for TCP-use-TLS, or b) nobody cares enough about TCP-use-TLS to do the obvious work. David _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
