Hi, On 2014-7-30, at 19:04, Joe Touch <[email protected]> wrote: > That goal is probably much more quickly and easily addressed by encouraging > use of TLS (https, IMAP/POP with TLS, etc.), and encouraging servers to > either get certificates signed by a known authority or at least self-signed.
using TLS requires changes to the application on both endpoints. If you only control one endpoint, you need some other out-of-band signal that the other end is upgraded to understand TLS, so you don't confuse it by sending a ClientHello or STARTTLS where none was expected. So it's not so simple. Also, for systems that incorporate many different application-level protocols that would all need to be updated, a TCP-level solution addressing all of them simultaneously is quite attractive. Finally, there are systems where a relatively small and contained patch to the TCP stack (e.g., something like tcpcrypt) is easier to implement, test and deploy than an approach that introduces dependencies on a TLS library (no matter how profiled down it may be in the future). Additional complexities may arise if that library does not already support being run in kernel context and/or has a license that makes such usage problematic, esp. for commercial products. (I fully understand that the final paragraph here is irrelevant from an IETF standards perspective, but it is important for someone who'd actually like to ship and deploy things.) Lars > That would side-step the need to modify TCP (a huge hurdle in comparison) and > all the NAT traversal issues (which already generally support TLS except in > cases where TCP encryption is likely to fail too - e.g., for some regions > where the snooped traffic has to match a visible known profile). > > Given TLS support is already available and in widespread use for the most > common apps (web, email), why not just do this via a BCP rather than creating > a new protocol with its related complexities? > > Joe > >> >> >> >> From: Stephen Kent <[email protected] <mailto:[email protected]>> >> Date: Tuesday, July 29, 2014 1:17 PM >> To: "[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>> >> Subject: Re: [tcpinc] Protect or not the TCP header >> >> +1 >> >>> On 2014-7-29, at 8:58, marcelo bagnulo braun<[email protected]> wrote: >>>> the charter reads: >>>> >>>> - must always provide integrity protection of the payload data (it is >>>> open for discussion for the WG if the TCP header should or should not >>>> be protected). >>>> >>>> So, I dont think we can clarify this, since it is up to the WG to figure >>>> it out. >>> So we do still need to figure it out :-) >>> >>> My personal take is that the main goal of tcpinc is to make the widespread >>> eavesdropping on plaintext connections harder. So focus the focus should be >>> on the payload, and interoperability should trump protection against other >>> attacks. >>> >>> I fully understand that there are different opinions on this, and they are >>> equally valid. But we need to figure out where the consensus of the WG on >>> this lies. >>> >>> Lars >>> >>> >>> _______________________________________________ >>> Tcpinc mailing list >>> [email protected]https://www.ietf.org/mailman/listinfo/tcpinc >> >> >> >> _______________________________________________ >> Tcpinc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tcpinc >> > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
