Subject: [tcpinc] Action needed now: Ways forward for TCPINC!

From: Martin Stiemerling <[email-masked]>
Date: Thu, 16 Jul 2015 12:33:26 +0200

Dear all,

The chairs summarized the current state of the TCPINC WG with respect to 
the selection of a WG protocol item in their email on 7/15.

Up to now, the WG could not reach rough consensus if any of the current 
protocol proposals can be used as the WG item. The two actively 
discussed protocol proposals are:

I) https://datatracker.ietf.org/doc/draft-rescorla-tcpinc-tls-option/
II) https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpcrypt/

The chairs passed the token to me and asked for guidance how to continue.

Here is my guidance:

The WG has to agree on a way forward and I have two proposed ways 
forward below.

In case, the WG cannot agree on any way forward, the WG will be still in 
a deadlock. This deadlock has not been removed within the last four 
months. A WG in a deadlock situation is not a WG anymore and I will 
close the WG, if there is no agreement on the way forward.

Here are the two propposed ways forward:

1) As neither the protocol proposal I) nor II) is achieving rough 
consensus, I propose to accept both as WG items and to let the WG work 
on both proposals until the IETF-94 meeting in November 2015. The WG 
will evaluate both proposals after this period and the chairs will last 
call to see which protocol proposal will achieve rough consensus.

2) The WG will ask the responsible AD to choose either I) or II) as WG 
item. The responsible AD will pick and the WG will accept the choice.

Please state your opinion if you are in favor of option 1) or 2) until 
July 20th, 11:30 am CEST, by email to the tcpinc WG list.

I will ask the chairs to make a judgement at the end of the response 
period on whether there is rough consensus on any of the questions. The 
result will be presented in the tcpinc meeting. This meeting is being 
held on the same day, July 20, at 3:20 pm CEST.

Thanks,

   Martin

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Jul 2015 11:48:59 +0100

with no hats:

> item. The responsible AD will pick and the WG will accept the choice.

I prefer (2) as I think it's likely we'd end up there in November
anyway and I think if the WG do start from either (I) or (II) then
we'll end up with a satisfactory result which is probably one of
the reasons we've not been able to choose to date and so having the
AD decide the starting point now is lower risk than (1). Option (1)
also I think has a high risk of nothing much happening until
November as the proponents of (I) and (II) might end up just
polishing their drafts a bit more which could make them even harder
to pick between.

Thanks though for the logjam-breaking, I think it's needed and worth
doing to get a result.

S.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 16 Jul 2015 13:36:17 +0200

hi Martin, all,

in the interests of providing some (also hatless) contrast...

> On 16 Jul 2015, at 12:33, Martin Stiemerling <[email-masked]> wrote:
> 
> 1) As neither the protocol proposal I) nor II) is achieving rough consensus, I propose to accept both as WG items and to let the WG work on both proposals until the IETF-94 meeting in November 2015. The WG will evaluate both proposals after this period and the chairs will last call to see which protocol proposal will achieve rough consensus.

I would be in favor of this way forward.

I think one of the fundamental issues here is that the WG has been asked to form consensus around one of two proposals, both of which are relatively mature but in completely different ways. Without a bit more implementation and experimentation experience, it's very difficult to make an informed decision between (1) a completely new protocol and (2) a mechanism for using an established protocol which has not yet been widely used in the way envisioned by the WG.

> 2) The WG will ask the responsible AD to choose either I) or II) as WG item. The responsible AD will pick and the WG will accept the choice.

This way forward makes sense IMO only if the choice between the two proposals is arbitrary. I don't think we know enough to say that yet.

Cheers,

Brian

> Please state your opinion if you are in favor of option 1) or 2) until July 20th, 11:30 am CEST, by email to the tcpinc WG list.
> 
> 
> I will ask the chairs to make a judgement at the end of the response period on whether there is rough consensus on any of the questions. The result will be presented in the tcpinc meeting. This meeting is being held on the same day, July 20, at 3:20 pm CEST.
> 
> Thanks,
> 
>  Martin
> 
> 
> 
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 16 Jul 2015 16:56:41 +0300

On Thu, Jul 16, 2015 at 01:36:17PM +0200, Brian Trammell wrote:
> will evaluate both proposals after this period and the chairs will
> last call to see which protocol proposal will achieve rough consensus.
> 

Me too.

> I think one of the fundamental issues here is that the WG has been
> asked to form consensus around one of two proposals, both of which
> are relatively mature but in completely different ways. Without a
> bit more implementation and experimentation experience, it's very
> difficult to make an informed decision between (1) a completely new
> protocol and (2) a mechanism for using an established protocol which
> has not yet been widely used in the way envisioned by the WG.

Maybe a stupid question, but is there an implementation of the TLS
option in the same style as tcpcrypt implementation?

Some comparision:

Tcpcrypt looks much simper than TLS, even after the downprofiling
done to TLS. There are lots of implementations of TLS, but none
look to be suited for running in supervisor mode[1].

I think the "passthrough" mode of TLS proposal looks unlikely to
work, unless both ends do it, which would relegate it to STARTTLS-
like mechanism. The reason is that "oppurtunistic" endpoints
can't interoperate with "non-oppurtunistic" ones, even if the
protocol is the "same".

Regarding maturity, when it comes to protocol security, maturity
does not matter, how solid the cryptographic engineering is does.
And unlike crypto primitives, protocols don't need to "age",
since secrity analysis does not change much with time. For
TLS, such security analysis was completed only quite recently
(revealing multiple security bugs in original design).

Some notes about tcpcrypt crypto:
- ECDH "groups" Curve25519 and Curve448 from CFRG could be added.
- Chacha20-Poly1305 (AEAD #29) could be added. Endpoints without
  hardware AES-GCM are much better with that[2].
- How are AEAD nonces generated exactly[3]? 128-bit crypto is
  bit on the low side. At full strength it is reasonable, but
  it doesn't take much to weaken it.

[1] Some of characteristics:
- Stacks are very limited (few kB, instead of few MB available
  in user mode).
- Consequences of implementation flaws are MUCH worse. Winshock
  was bad, but corresponding bug here would be truly catastrophic.
- No, one can't run garbage collector.

[2] Some perspective: When cloudflare set nonstandard TLS
Chacha20-Poly1305 ciphers at equal priority as AES-GCM ciphers,
~25% of AES-GCM usage shifted in less than half hour.

[3] E.g.:
- Is the nonce just zero-extended from its wire form?
- Can passive listener determine values of extension bits
  (none of TLS 1.2, IPSec AES-GCM nor SSH allow this)? 

-Ilari

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jul 2015 08:38:08 -0700

> Dear all,
...
> call to see which protocol proposal will achieve rough consensus.

That will ensure the group with more cycles will succeed, which is not
necessarily either the better solution nor will it generate consensus.

> item. The responsible AD will pick and the WG will accept the choice.

The IETF is based on rough consensus, and the ADs cannot simply decree
that. If the community has no rough consensus, then that should be the
result of the WG.

My concern is that we haven't seemed to have consensus on the
requirements., which is part of why we can't agree on a potential
solution. And if there's no agreement, it's inappropriate to generate WG
output that claims otherwise.

Joe

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Jul 2015 11:39:33 -0400

Martin,

I support your option #1 proposed way forward.

Steve

---

From: John Border <[email-masked]>
Date: Thu, 16 Jul 2015 15:44:56 +0000

+1

-----Original Message-----
From: Tcpinc [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: Thursday, July 16, 2015 7:36 AM
To: Martin Stiemerling
Cc: [email-masked]
Subject: Re: [tcpinc] Action needed now: Ways forward for TCPINC!

hi Martin, all,

Cheers,

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Jul 2015 08:56:31 -0700

On Thu, Jul 16, 2015 at 3:33 AM, Martin Stiemerling <[email-masked]>
wrote:Martin,

Thanks for jumping on this.

My basic principle here is that the proposals should be presented to
the WG and the WG should decide, even if consensus is rough.  We've
largely avoided doing that here in hopes that we could get one merged
proposal, but I agree is that that now seems unlikely.

> last call to see which protocol proposal will achieve rough consensus.

This seems like a reasonable way to proceed and consistent with our
practices (and what we have done in plenty of other contentious
situations). If the chairs and AD think that November is the time for that
decision I'm fine with that.

One minor procedural note on this: offline we'd discussed breaking
out a Transport Layer Negotiation Option which could negotiate
either tcpcrypt or TLS. If we're going to accept these both
as WG documents (which seems fine, though unnecessary, I suggest
we break that piece out).

> item. The responsible AD will pick and the WG will accept the choice.

I'm not in favor of this, even as a fallback. We already have an
alternative consensus process defined in RFC 3929, which, while highly
imperfect, still has several options with more legitimacy than AD
selection.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jul 2015 15:22:19 -0700

> output that claims otherwise.

PS - that'd be a fine document for the WG to focus on as a "proof of
concept" that convergence is possible, and if not, would certainly beg
the question of the appropriateness of picking a solution.

Joe

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 17 Jul 2015 00:25:37 +0200

Hi Martin, hi all,

I would like to vote for option 1 (adopt both) because I don’t think we should make an arbitrary choice here. 

If we further work on both proposal, there might even be a chance to find a solution to combine the best of both… :-) …?

Mirja

> Am 16.07.2015 um 12:33 schrieb Martin Stiemerling <[email-masked]>:
> 
> Dear all,
> 
> The chairs summarized the current state of the TCPINC WG with respect to the selection of a WG protocol item in their email on 7/15.
> 
> Up to now, the WG could not reach rough consensus if any of the current protocol proposals can be used as the WG item. The two actively discussed protocol proposals are:
> 
> The WG has to agree on a way forward and I have two proposed ways forward below.
> 
> In case, the WG cannot agree on any way forward, the WG will be still in a deadlock. This deadlock has not been removed within the last four months. A WG in a deadlock situation is not a WG anymore and I will close the WG, if there is no agreement on the way forward.
> 
>

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 16 Jul 2015 16:40:39 -0700

> 1) As neither the protocol proposal I) nor II) is achieving rough consensus, I propose to accept both as WG items and to let the WG work on both proposals until the IETF-94 meeting in November 2015…

+1 on 1)

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 17 Jul 2015 09:33:49 +0200

Martin,
> July 20th, 11:30 am CEST, by email to the tcpinc WG list.

Option 2 does not make sense. I vote for option 1 and hope to see more 
technical discussion on the list

Olivier

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 17 Jul 2015 18:43:05 +0200

I vote for option 1.

Although not directly related to this question, I'll also second ekr's
point about separating the transport negotiation piece out while allowing
the rest to proceed per one or two proposals.

On Thu, Jul 16, 2015 at 12:33 PM, Martin Stiemerling <[email-masked]>
wrote:

> protocol proposals can be used as the WG item. The two actively discussed
> protocol proposals are:
>
> In case, the WG cannot agree on any way forward, the WG will be still in a
> deadlock. This deadlock has not been removed within the last four months. A
> WG in a deadlock situation is not a WG anymore and I will close the WG, if
> there is no agreement on the way forward.
>
>
> consensus, I propose to accept both as WG items and to let the WG work on
> both proposals until the IETF-94 meeting in November 2015. The WG will
> evaluate both proposals after this period and the chairs will last call to
> see which protocol proposal will achieve rough consensus.
>
> result will be presented in the tcpinc meeting. This meeting is being held
> on the same day, July 20, at 3:20 pm CEST.
>
> Thanks,
>
>   Martin
>
>
>

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 17 Jul 2015 23:02:37 +0200

Hi Joe, all,

> necessarily either the better solution nor will it generate consensus.

That might be correct, but the IETF process has now way to balance 
between groups with more or less cycles. However, giving more time, but 
limited, will allow the WG to discuss both proposals. This isn't a 
guarantee for anything, but at least there is more time.

> that. If the community has no rough consensus, then that should be the

Please read my words carefully:
"The WG will ask the AD". This isn't an AD taking over and making a 
ruling, but the WG is explicitly asking the AD to make a decision. I 
will not decree any consensus. Just to make this statement clear.

> output that claims otherwise.

That is a fair point made.

   Martin

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Jul 2015 14:09:16 -0700

Hi, Martin,

> will not decree any consensus. Just to make this statement clear.

Whether you act with or without WG request (and I wasn't presuming you
would), having you make a selection is NOT "rough consensus".

If we go down that route, the document would need a very loud and
explicit statement that it does NOT reflect WG consensus.

Joe

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 19 Jul 2015 10:33:07 +0000

On 2015-7-16, at 12:48, Stephen Farrell <[email-masked]> wrote:
> anyway

Agree with Stephen on (2).

(And remain disappointed that the WG refused to come to rough consensus on the one proposal that has had actual running code for years now.)

Lars

---

From: Tim WIcinski <[email-masked]>
Date: Sun, 19 Jul 2015 16:30:07 +0200

Having read both of these, I'm siding with option 1.

i'd be willing to review documents, but tcpinc conflicts with dnsop for me.

tim

---

From: Eric Smith <[email-masked]>
Date: Sun, 19 Jul 2015 14:27:35 -0700

I support option 1.

-Eric Smith

On 7/16/15 3:33 AM, Martin Stiemerling wrote:
> Dear all,
>
> The chairs summarized the current state of the TCPINC WG with respect 
> to the selection of a WG protocol item in their email on 7/15.
>
> Up to now, the WG could not reach rough consensus if any of the 
> current protocol proposals can be used as the WG item. The two 
> actively discussed protocol proposals are:
>
> In case, the WG cannot agree on any way forward, the WG will be still 
> in a deadlock. This deadlock has not been removed within the last four 
> period on whether there is rough consensus on any of the questions. 
> The result will be presented in the tcpinc meeting. This meeting is 
> being held on the same day, July 20, at 3:20 pm CEST.
>
> Thanks,
>
>   Martin
>
>
>

---

From: John-Mark Gurney <[email-masked]>
Date: Sun, 19 Jul 2015 15:17:52 -0700

> call to see which protocol proposal will achieve rough consensus.

It seems like things are slowly progressing so option 1 makes the most
sense at this time...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

---

From: David Mazieres <[email-masked]>
Date: Sun, 19 Jul 2015 20:31:12 -0700

The time to vote on this question is approaching.  Forced to vote, I
chose #1 (keep both drafts going for now).  But I think we must
appropriately modify the instructions to authors going forward so as to
avoid wasting four months.

Keeping the bigger goal in mind, we should vote for the option that
results in the highest fraction of TCP connections carrying encrypted
traffic.  The reason I think waiting four months (with the right actions
July 20) could further that goal is that TCPINC is really solving *two*
problems:

  1. Let application authors adopt encryption even when protocols do not
     contain room for negotiation (i.e., can't squeeze in a STARTTLS).
     In this case, it is okay to have source code changes.

  2. Let systems deploy encryption without modifying existing programs
     or in cases where for whatever reason TLS does not fit.

Having the AD just pick a winner tomorrow would be good for goal #1,
because both proposals provide the necessary out-of-band negotiation for
encryption, and an earlier decision would lead to earlier deployment.
However, I believe this would not be good for goal #2, particularly if
we go with TCP-use-TLS, which to my mind is tailor-made for a library
implementation.  In fact, I'd go so far as to say that TCP-use-TLS could
actually be *improved* if it weren't hamstrung by the need to maintain
API compatibility with TCP.  For instance, without such a restriction,
TCP-use-TLS applications could express information about domain names to
the protocol and benefit from TLS's certificate machinery.

Tcpcrypt, by virtue of being designed to be implemented in TCP or as a
packet rewriter, is going to be easier to make work in case #2.  There's
a reason that so far only tcpcrypt has provided an implementation that
works with unmodified binaries.

All of this makes me wonder if there might not actually be room for both
protocols on the Internet.  With that in mind, if we go forward with
both protocols, rather than charge the two groups with identical
instructions, we should task them with different requirements in the
hopes of getting out a pair of protocols that truly maximizes encryption
of TCP traffic.

Specifically, suppose we instructed authors of the two drafts as
follows:

  * Tcpcrypt should be modified to provide application-level signaling
    for TCP-use-TLS.  It already has support for application-aware bits,
    which means the draft must evolve to add support for an
    "application-prefers-TLS" option and an
    "application-declines-tcpcrypt-but-wants-TLS" option.  We would
    probably rework things so this mode negotiation is cleaner (a byte
    with various option bits).

  * TCP-use-TLS should be freed from the notion that it someday needs to
    live in the TCP stack, and should therefore be optimized for a
    library implementation.  It's goal should be to achieve the best
    design possible *with API changes*.

These goals can be furthered without making the two protocols dependent
on each other's success.  The tcpcrypt protocol can make support for
TCP-layer encryption a SHOULD rather than a MUST, so that if TCP-use-TLS
end up far more popular, people don't have to stick the rest of tcpcrypt
into their kernels.  Likewise, if tcpcrypt turns out to be preferable in
practice, people don't have to link their applications with the
TCP-use-TLS library.

David

---

From: Brian Trammell <[email-masked]>
Date: Mon, 20 Jul 2015 13:58:23 +0200

hi David,

thanks for this message; this seems like a good way forward. Jumping back into the thread, a couple of no-hat points inline...

> On 20 Jul 2015, at 05:31, David Mazieres <[email-masked]> wrote:
> 

I agree with this completely -- I support (1) not because it's a good choice, but the less-bad of the two presented.

>    with various option bits).

This instruction also has the nice property that it supports the long transition from goal 2 to goal 1: protecting the confidentiality traffic of an application protocol while it transitions to providing confidentiality and authentication itself.

>    design possible *with API changes*.

So I'm not *quite* clear as to what you mean by "with API changes" here. What I think you mean is that there would be an additional API available to provide an environment between "it just works out of the box if you link it with a different library, allowing applications to 'ease in' to using TLS. If that's what you mean, then I would be very much in favor of it, as it leads to a design with an explicit provision for transition.

> on each other's success.

...though I would observe that the TCP options footprint used by the two protocols seems to have converged to having more or less the same properties in the face of middlebox interference; there may then be some advantage to both proposals using a common set of behaviors to fall back and work around here. This is perhaps bit much of an optimization at this point in time, but the point is there may be areas of common work between the two protocols...

Thanks, cheers,

Brian

>  The tcpcrypt protocol can make support for