On Sun, Aug 2, 2015 at 2:25 PM, Christian Huitema <[email protected]> wrote: > 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.
You didn't answer the question, but half of it. Okay, I'll provide the other half, where we use tcpcrypt instead. We'll use two bits: will offer tls, will offer tcpcrypt, and fall back to tls otherwise. > > "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. So in my above proposal we end up with tcpcrypt protecting the channel, as what was the shim indicates it wants tcpcrypt, and the negotiation works. > > "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. This is symmetric with above. Or am I missing something? So once again both proposals do the same thing. Can someone beat the donkey until it decides? > > The obvious issue is the potential for downgrade attacks and MITM insertion, > but that's something LS has to deal with anyhow. > > -- Christian Huitema > > > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
