Eric, Your draft in fact addressed the issue that I'm concerned about. I'm focused on using something like TCPINC in kernel-to-kernel TCP communication. Your section 5 calls out implementation of the kernel option as "more effort for kernel developers". In my case, there's no user-space application to which the kernel can kick the negotiation of TLS, so the kernel option is the only option.
Craig From: Eric Rescorla <[email protected]<mailto:[email protected]>> Date: Tuesday, July 29, 2014 11:19 AM To: Craig Everhart <[email protected]<mailto:[email protected]>> Cc: Christian Huitema <[email protected]<mailto:[email protected]>>, Mark Handley <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [tcpinc] Protect or not the TCP header On Tue, Jul 29, 2014 at 7:58 AM, Everhart, Craig <[email protected]<mailto:[email protected]>> wrote: On 7/29/14 1:58 AM, "Christian Huitema" <[email protected]<mailto:[email protected]>> wrote: >Let look at TCP + crypto. It has to compete with two established >standards. >On one hand, TLS, which is easily deployed but does not protect any of the >TCP headers. On the other hand, IPSEC, which is harder to deploy but does >protect the TCP header. A secure version of TCP only makes sense if it >protects the headers better than TLS and is easier to deploy than IPSEC. I don't think TLS is so easy to deploy. TCP is used in a wide variety of environments; that's one of its attractions. One of the attractions of TCPcrypt is its aim to be deployable wherever TCP can be, which is a bigger space than where TLS is convenient. That's my hope for the WG. Can you say more about why TLS is hard to deploy? I'm particularly interested in issues which aren't addressed by my draft. Thanks, -Ekr
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
