On Sunday, August 2, 2015 11:12 AM, David Mazieres wrote: > 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. > ... > 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.
I too have a strong preference for EKR's draft (a). My main reason is that I see TCP INC as a transition technology, deploying opportunistic encryption first but evolving quickly to strong encryption with authentication. TLS compatibility facilitates that transition. My other reason is that I would much rather maintain a single security stack instead of two. I have been pondering these issues for some time. I liked the initial TCP-crypt design a lot, but my attraction to it vanished after the "middle-box" compromise. The TCP security protection cannot protect the TCP protocol elements, because doing so would be incompatible with existing middle-boxes. But then we are left with running a security filter on top of TCP, and that's exactly what TLS does. The question then is whether we deploy a light weight security filter like the current TCP crypt design, or whether we just find a way to shim TLS between the current TCP API and the application. I much prefer the TLS option. The main argument for TCP Crypt is the cost of implementation. That argument rings a bit hollow for a Windows kernel developer, since we have in fact access to S-Channel in the Windows kernel. Windows web servers rely on the HTTP.SYS kernel driver, which implements TLS using the kernel API for S-Channel. HTTP.SYS has been doing that for a long time, so there is indeed some experience with that solution. The other argument for the light weight filter is that the protocol can be smaller, and thus easier to verify, debug, or even prove. The protocol may indeed be smaller, but the size effect mostly comes from leaving out authentication. Without authentication, there is no need for verifying certificates. If one leaves certificate negotiation out, TLS is pretty small. The next big chunk of complexity comes from algorithm agility, but I fully expect that any standardized version of TCP crypt will have to incorporate some support for algorithm agility. At that point, we would have two stacks to implement, which means twice the attack surface and twice the number of potential security bugs. The logical argument that swayed me towards reusing TLS is the evolution towards authentication. We want to deploy TCP INC to enable opportunistic encryption of old applications that have not yet been upgraded to "Start TLS." But we do not want these applications to be stuck at the "opportunistic" level. The solution in TCP crypt is to use a channel binding API so authentication can be later implemented inside the application. That works, but it requires applications to manage secrets, and points to the evolution of an enlarged TCP crypt stack that would incorporate authentication based on channel binding, and effectively compete with the TLS solutions. At that point, the risk of twice the attack surface and twice the bugs becomes really concerning, not to mention the confusion of two IETF standards to achieve the same thing. The "TLS filter" approach provides a simpler evolution path. System administrators first use a system option to insert a TLS shim under unprotected applications. In parallel, applications start evolving and adopt a way to "Start TLS." We get a transition state in which the TLS layer incorporated in an application talks to the shim under an unmodified responder. The system administrator initially provision the shim with a self-signed certificate, but may upgrade to a regular certificate and provide actual authentication. All that looks like a clean evolution. _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
