Re: [tcpinc] Call for adoption of draft-rescorla-tcpinc-tls-option-05

I do not support putting TLS into TCP.

It is a heavyweight, one size fits all, baggage laden protocol.  Putting 
something complicated and baggage-laden into TCP is going to harm the 
overall goal of TCPINC - get some lightweight opportunistic encryption 
out there where we can, because the alternate is no security.

 From an engineering perspective, putting TLS into TCP increases the 
chances of no security, IMHO.

iang

On 20/10/2015 17:49 pm, Mirja Kühlewind wrote:
> Hi all,
>
> please indicate if you support adoption of
> draft-rescorla-tcpinc-tls-option-05 as a tcpinc working group item, or
> not, by
>
>      Monday, Nov 2, 2015.
>
> draft-rescorla-tcpinc-tls-option is one candidate for tcpinc where the
> first version of this draft was proposed more than a year ago. Verison
> -04 was release about three weeks ago and specifies the TLS 1.3 profile
> as well as the use of draft-rescorla-tcpinc-tls-option with tcp-eno.
> Since then this draft received a lot of discussion. The lasted update
> was provided yesterday, but only changes a few minor fixes.
>
> Similar as before, if you do not support adoption of this document
> because you think it is not in scope for the wg or has fundamental
> technicals flaws and would therefore harm the goals of the wg, it would
> be great if you could given some reasoning/explanation with your response.
>
> This is solely an adoption call for draft-rescorla-tcpinc-tls-option
> independent of any other documents. If you have a personal preference
> for a different approach that should not be a reason to reject this
> adoption. Forcing the wg to make a decision has not worked previously,
> and even though both proposed approaches have evolved, I do not see any
> indication that the wg is now ready to make a decision. The goal of this
> adoption call is to figure out if there is enough interest and energy to
> further follow the approach as outlined in
> draft-rescorla-tcpinc-tls-option-05.
>
> This process may lead to the situation where the wg will adopt and work
> on two solution approaches. This does not mean that the wg will publish
> two (incompatible) approaches, as this would not fulfill our charter. If
> we end up adopting more than one approach, I currently see three way to
> proceed:
>
> 1) Both approaches (naturally) converge into one approach.
>
> 2) We work on both approaches to get them into a (similar) state where
> the wg is able to make a decision (and withdraw the other doc).
>
> 3) We publish both approaches as different 'versions' of tcpinc that can
> be negotiated in the tcp-eno handshake, where at least one of them is
> mandatory to support/implement.
>
> Thanks!
> Mirja
>
> _______________________________________________
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc
>