Subject: [tcpinc] Call for adoption of draft-bittau-tcpinc-tcpcrypt-04

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 20 Oct 2015 18:47:43 +0200

Hi all,

please indicate if you support adoption of draft-bittau-tcpinc-tcpcrypt-04 as 
a tcpinc working group item, or not, by

	Monday, Nov 2, 2015.

draft-bittau-tcpinc-tcpcrypt is one candidate for tcpinc where the first 
version of that draft was proposed about a year ago. In the mean time this 
proposal has received broad feedback. The latest version was published only a 
few days ago, however, this version adapts the tcpcrypt proposal to tcp-eno, 
which we adopted as a wg item a couple weeks ago, and therefore simplifies 
the draft.

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-bittau-tcpinc-tcpcrypt 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-bittau-tcpinc-tcpcrypt-04. A separate adoption call for the other 
proposed solution will following.

This process may lead to a 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Oct 2015 23:48:50 +0100

Given the choices presented, I support adoption of this draft.

S.

On 20/10/15 17:47, Mirja Kühlewind wrote:
> Hi all,
> 
> please indicate if you support adoption of
> draft-bittau-tcpinc-tcpcrypt-04 as a tcpinc working group item, or not, by
> 
>     Monday, Nov 2, 2015.
> 
> version of that draft was proposed about a year ago. In the mean time
> this proposal has received broad feedback. The latest version was
> published only a few days ago, however, this version adapts the tcpcrypt
> proposal to tcp-eno, which we adopted as a wg item a couple weeks ago,
> and therefore simplifies the draft.
> 
> 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-bittau-tcpinc-tcpcrypt
> 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
> This process may lead to a 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:
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Oct 2015 16:44:53 -0700

On Tue, Oct 20, 2015 at 9:47 AM, Mirja Kühlewind <
[email-masked]> wrote:

> Hi all,
>
> please indicate if you support adoption of draft-bittau-tcpinc-tcpcrypt-04
> as a tcpinc working group item, or not, by
>
>         Monday, Nov 2, 2015.
>
> proposal has received broad feedback. The latest version was published only
> a few days ago, however, this version adapts the tcpcrypt proposal to
> tcp-eno, which we adopted as a wg item a couple weeks ago, and therefore
> simplifies the draft.
>
>
> ​

> 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-bittau-tcpinc-tcpcrypt-04. A separate
> adoption call for the other proposed solution will following.
>

​I support adoption of this draft on this basis.

Ted​

> 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).
>

---

From: David Mazieres <[email-masked]>
Date: Tue, 20 Oct 2015 21:08:12 -0700

Unsurprisingly, I support adoption of draft-bittau-tcpinc-tcpcrypt-04.

Tcpcrypt is simple, relatively self-contained, and custom tailored to
the goals of the TCPINC working group.  It has no external dependencies
that could block progress.  Tcpcrypt is also well suited for
implementation in TCP stacks, where one doesn't always have access to
the usual set of system libraries.  Furthermore, I believe it is a huge
advantage for TCPINC to have full change control of the protocol.
Tcpcrypt has already undergone multiple changes in response to the
working group.  Once it is adopted, we will have full freedom to address
any further concerns in the simplest way possible.

I also believe there's value in having protocol diversity, so we don't
put all our eggs in one basket.  I like the fact that when a
vulnerability is discovered in an SSL implementation, I can SSH to my
server to upgrade my library.  Because SSH doesn't use SSL, at least my
SSH connection isn't susceptible to the same problem.  Of course SSH,
too, may have problems, but I can guard against those with OpenVPN.  So
the world is clearly better off for having both SSL and SSH, and I see
tcpcrypt becoming a valuable third tool in our arsenal.

David

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 21 Oct 2015 07:45:42 +0000

Support

Lars

---

From: Mark Handley <[email-masked]>
Date: Wed, 21 Oct 2015 11:37:26 +0100

I support this draft too (no surprise there!).  To be clear though,
although I prefer tcpcrypt, I believe either approach would be much
better than doing nothing.  

Of your three ways to proceed, I think (1) is unlikely to occur because
the difference is philosophical rather than just technical.

Mark

On Tue, Oct 20, 2015, at 05:47 PM, Mirja Kühlewind wrote:
> this 
> not 
> independent 
> two 
> end 
> the wg 
> be

---

From: ianG <[email-masked]>
Date: Thu, 22 Oct 2015 10:28:01 +0100

I support adoption of Bittau / tcpcrypt.  We need something that is 
light, focused and has precise experience backing its deployment.

iang

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 22 Oct 2015 23:19:07 +0100

On Tue, Oct 20, 2015 at 06:47:43PM +0200, Mirja Kühlewind wrote:
> a tcpinc working group item,

I support its adoption.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 22 Oct 2015 18:25:28 -0400

>> a tcpinc working group item,

I support adoption

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 23 Oct 2015 08:11:11 +0200

Greetings, all,

I support the adoption of draft-bittau-tcpinc-tcpcrypt as a WG item.

Cheers,

Brian

> On 20 Oct 2015, at 18:47, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi all,
> 
> please indicate if you support adoption of draft-bittau-tcpinc-tcpcrypt-04 as a tcpinc working group item, or not, by
> 
> 	Monday, Nov 2, 2015.
> 
> draft-bittau-tcpinc-tcpcrypt is one candidate for tcpinc where the first version of that draft was proposed about a year ago. In the mean time this proposal has received broad feedback. The latest version was published only a few days ago, however, this version adapts the tcpcrypt proposal to tcp-eno, which we adopted as a wg item a couple weeks ago, and therefore simplifies the draft.
> 
> 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-bittau-tcpinc-tcpcrypt 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-bittau-tcpinc-tcpcrypt-04. A separate adoption call for the other proposed solution will following.
> 
> This process may lead to a 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:
> 
> 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
> 
> 
>

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 28 Oct 2015 20:10:29 -0700

I support tcp-crypt for WG item.

btw the current draft is much better than it was in March, from primarily a
TCP implementor's perspective.

---

From: Mirja Kühlewind <[email-masked]>
Date: Sat, 31 Oct 2015 11:49:32 +0900

Hi all,

just a reminder that there are two days left to provide feedback on the adoption of 

	draft-bittau-tcpinc-tcpcrypt-04

David & Mirja

> Am 21.10.2015 um 01:47 schrieb Mirja Kühlewind <[email-masked]>:
> 
> Hi all,
>

---

From: "Everhart, Craig" <[email-masked]>
Date: Sat, 31 Oct 2015 20:03:50 +0000

I support the adoption of this document as a WG item.

Craig Everhart

On 10/30/15, 10:49 PM, "Tcpinc on behalf of Mirja Kühlewind"
<[email-masked] on behalf of [email-masked]>
wrote:

>> draft-bittau-tcpinc-tcpcrypt is one candidate for tcpinc where the
>>first version of that draft was proposed about a year ago. In the mean
>>time this proposal has received broad feedback. The latest version was
>> This process may lead to a 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:
>> 
>> 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
>> 
>> 
>>