On Sunday, August 2, 2015 1:37 PM, Watson Ladd wrote: > > On Sun, Aug 2, 2015 at 1:30 PM, Christian Huitema <[email protected]> > wrote: > > On Sunday, August 2, 2015 12:52 PM, John-Mark Gurney wrote: > >> > >> ... > >> It's sounds like you view TLS-use-TCP as doing full certificate parsing > >> and validation in the kernel, is this correct? > > > > There are multiple ways to implement a shim between application and TCP. > If I implemented this in the Windows kernel, I would use the existing kernel > API. But I can see many other ways. > > > > Your specific question on certificate is a matter of profiles. EKR proposed > "ECDH anon with P256 and Curve25519." This is "anonymous Diffie-Helman > with elliptic curves." It does not involve any certificate at all. > > Your email talked about authentication. Was that going to interact > with the shim, or just signal to the app that it should do TLS? If the > second, what is the gain from using TLS over TCP instead of opting out > of tcpcrypt if the app will do TCP?
There are four scenarios, "shim to shim", "full to shim", "shim to full", and "full to full," where full is a complete implementation of TLS and shim is the subset. Obviously, shim to shim works as long as the two ends have the same shim, and full to full works as long as the two ends implement TLS. "Full to shim" sees one client implementing full TLS, and presumably using an IOCTL to disable the shim implementation. If the TLS options proposed by the client are a superset of the TLS options used by the shim, and if the ENO option is used right, we end up with the same TLS over TCP variant as shim to shim. "Shim to full" sees one server implementing full TLS, presumably using some "start TLS" variant. The shim is systematically disabled on the server's sockets. The ENO option advises the server to switch on TLS, rather than wait for the "Start TLS" message. As long as the TLS options accepted by the server include the options proposed by the shim, we end up with the same TLS over TCP variant as shim to shim. The obvious issue is the potential for downgrade attacks and MITM insertion, but that's something LS has to deal with anyhow. -- Christian Huitema _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
