Subject: [tcpinc] CORRECTION: Reminder: Ongoing Working Group Last Call about drafts to choose as WG item

From: Martin Stiemerling <[email-masked]>
Date: Fri, 24 Jul 2015 04:16:39 -0500

Dear all,

**Please use this CORRECTED version, as one option to choose from below 
didn't make it into the original.****
Thanks to Erik Rescola for pointing this out to me directly.

This point got lost on the mailing list, but it has been decided in the 
WG session here at IETF-93 that there will be a Last Call for consensus 
about which document of the below ones to take as starting point for the WG.

Here are the two drafts:
a) draft-rescorla-tcpinc-tls-option-03
b) draft-bittau-tcpinc-tcpcrypt-03

Please respond to the tcpinc wg mailing list until

    July 31st, 2015
    1pm CEST

on wether you prefer
- either draft a) or b)
- both drafts (a & b) as WG items
- or none

to be accepted as WG item(s).

Please write also your brief reasoning on why you made your choice.

Please note that accepting a draft is not the end of working on the 
technical content of the draft, but it is actually the starting point 
when the WG has full change control about the content of the draft!

Regards,

   Martin Stiemerling
   Transport Area Director

---

From: Ted Hardie <[email-masked]>
Date: Fri, 24 Jul 2015 11:24:23 +0200

Hi Martin,

Thanks for the correction, but I confess I'm still a little confused.  I
understood in the room that you saw rough consensus on the list to go
forward with both, based on the call that went to the list and ended on the
20th.  This was something Mirja and I both argued for, and the minutes note
you saying "Martin: look at the mailing list. There is consensus about
adopting both. There is tine to work on both."

When I saw the message, I thought that you were confirming on the list that
this was the way forward, but this message appears to re-open the question
from the start.  I'd really rather we didn't start over again.  Can we
start with the sense of the room/previous list consensus instead, and look
only to see if there is a groundswell of objection from those not in the
room?

I have not, mind you, looked at the recordings yet, and if you would like
to before making a further adjustment, I'd certainly understand.

Thanks,

Ted

On Fri, Jul 24, 2015 at 11:16 AM, Martin Stiemerling <[email-masked]>
wrote:

> This point got lost on the mailing list, but it has been decided in the WG
> session here at IETF-93 that there will be a Last Call for consensus about
> which document of the below ones to take as starting point for the WG.
>
>
> Here are the two drafts:
> technical content of the draft, but it is actually the starting point when
> the WG has full change control about the content of the draft!
>
>
> Regards,
>
>   Martin Stiemerling
>   Transport Area Director
>
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Jul 2015 11:28:30 +0200

> adopting both. There is tine to work on both."

This matches my understanding of the understanding of what happened
in the room and is confirmed by my review of the minutes.

-Ekr

> When I saw the message, I thought that you were confirming on the list
> that this was the way forward, but this message appears to re-open the
> question from the start.  I'd really rather we didn't start over again.
> Can we start with the sense of the room/previous list consensus instead,
> and look only to see if there is a groundswell of objection from those not
> in the room?
>

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 24 Jul 2015 04:33:44 -0500

Hi Ted,

Am 24.07.15 um 04:24 schrieb Ted Hardie:
> forward with both, based on the call that went to the list and ended on
> the 20th.  This was something Mirja and I both argued for, and the
> minutes note you saying "Martin: look at the mailing list. There is
> consensus about adopting both. There is tine to work on both."
>
> and look only to see if there is a groundswell of objection from those
> not in the room?
>
> I have not, mind you, looked at the recordings yet, and if you would
> like to before making a further adjustment, I'd certainly understand.

This call is a simple procedural step:
There were hums in the session on whether to go for just a), just b), or 
both. This call is simply to confirm the hums out of the WG session on 
the list, no more.

Everything out of the a WG meeting needs to be confirmed on the mailing 
list. I do not think that anybody is disagreeing about this, right?

Thanks,

   Martin

>
> Thanks,
>
> Ted
>
> On Fri, Jul 24, 2015 at 11:16 AM, Martin Stiemerling <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Dear all,
>
>     **Please use this CORRECTED version, as one option to choose from
>     below didn't make it into the original.****
>     This point got lost on the mailing list, but it has been decided in
>     the WG session here at IETF-93 that there will be a Last Call for
>     consensus about which document of the below ones to take as starting
>     point for the WG.
>
>
>     Here are the two drafts:
>     technical content of the draft, but it is actually the starting
>     point when the WG has full change control about the content of the
>     draft!
>
>
>     Regards,
>
>        Martin Stiemerling
>        Transport Area Director
>
>     [email-masked] <mailto:[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 24 Jul 2015 12:19:51 +0200

Hi Martin,

On Fri, Jul 24, 2015 at 11:33 AM, Martin Stiemerling <[email-masked]>
wrote:

> ​
> both. This call is simply to confirm the hums out of the WG session on the
> list, no more.
>
​Of course everything needs to be confirmed on the list, but I'm used to
folks recording the consensus from the room as part of the call for
confirmation.  I was a bit confused without that, because this looked like
a restart of the discussion.  If we are agreed on what the result of the
meeting was (that both are going to go forward for further work) and are
confirming that, then I think my confusion is resolved now.

For final confirmation, do you wish to have those of us who were (probably
over) vocal in the meeting to record our voices again here?

regards,

Ted​

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Jul 2015 12:28:45 +0200

> confirming that, then I think my confusion is resolved now.

For reference, this is memorialized in Tero's mail from Tuesday:
http://www.ietf.org/mail-archive/web/tcpinc/current/msg00577.html

-Ekr

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 24 Jul 2015 12:55:42 +0000

b

---

From: Derek Fawcus <[email-masked]>
Date: Fri, 24 Jul 2015 18:50:45 +0100

As being in one complete document it'll be easier to comprehend,
there is some current runing code,  and it strikes me a more
likely to see actual deployment than the 'use TLS' approach,
especially in a kernel.

DF

---

From: David Mazieres <[email-masked]>
Date: Fri, 24 Jul 2015 14:14:58 -0700

> b) draft-bittau-tcpinc-tcpcrypt-03

As you would expect since I am a co-author, I prefer this option.  My
reasons are that it increases diversity, is more specifically suited to
TCP, is simpler and more self-contained, and--because it isn't anchored
to another working group's specification--will be easier to modify to
accommodate whatever issues arise.

David

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 27 Jul 2015 09:50:23 +0200

Am 24.07.15 um 12:19 schrieb Ted Hardie:
> Hi Martin,
>
> On Fri, Jul 24, 2015 at 11:33 AM, Martin Stiemerling <[email-masked]
>     There were hums in the session on whether to go for just a), just
>     b), or both. This call is simply to confirm the hums out of the WG
>     session on the list, no more.
>
>     Everything out of the a WG meeting needs to be confirmed on the
>     mailing list. I do not think that anybody is disagreeing about this,
>     right?
>
>
> confirmation.  I was a bit confused without that, because this looked
> like a restart of the discussion.  If we are agreed on what the result
> of the meeting was (that both are going to go forward for further work)
> and are confirming that, then I think my confusion is resolved now.

We confirm the hums out of the session at IETF-93. This includes to 
confirm on the list that there is or isn't rough consensus for either 
a), b), (a & b) or none.

>
> For final confirmation, do you wish to have those of us who were
> (probably over) vocal in the meeting to record our voices again here?

Yes, please!

Thank you,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 27 Jul 2015 09:51:57 +0200

Hi Eric,

Am 24.07.15 um 11:28 schrieb Eric Rescorla:
>
> On Fri, Jul 24, 2015 at 11:24 AM, Ted Hardie <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Martin,
>
>     Thanks for the correction, but I confess I'm still a little
>     confused.  I understood in the room that you saw rough consensus on
>     the list to go forward with both, based on the call that went to the
>     list and ended on the 20th.  This was something Mirja and I both
>     argued for, and the minutes note you saying "Martin: look at the
>     mailing list. There is consensus about adopting both. There is tine
>     to work on both."
>
>

To make it again clear: Any call for consensus in a meeting has to be 
confirmed on the list. This is happening right now.

I do not believe that there is a doubt that the WG hummed for a), b), or 
adopting both, isn't it?

   Martin

>
> -Ekr
>
>     When I saw the message, I thought that you were confirming on the
>     list that this was the way forward, but this message appears to
>     re-open the question from the start.  I'd really rather we didn't
>     start over again.  Can we start with the sense of the room/previous
>     list consensus instead, and look only to see if there is a
>     groundswell of objection from those not in the room?
>
>     On Fri, Jul 24, 2015 at 11:16 AM, Martin Stiemerling
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>         Dear all,
>
>         **Please use this CORRECTED version, as one option to choose
>         from below didn't make it into the original.****
>         This point got lost on the mailing list, but it has been decided
>         in the WG session here at IETF-93 that there will be a Last Call
>         for consensus about which document of the below ones to take as
>         starting point for the WG.
>
>
>         Here are the two drafts:
>         Please note that accepting a draft is not the end of working on
>         the technical content of the draft, but it is actually the
>         starting point when the WG has full change control about the
>         content of the draft!
>
>
>         Regards,
>
>            Martin Stiemerling
>            Transport Area Director
>

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 27 Jul 2015 10:11:46 +0000

(B) because I can use it, in a kernel (FreeBSD) environment, and I like its simple approach to authentication.  It provides a broader base of applicability--not just userspace connections.

Craig

----- Reply message -----
From: "Martin Stiemerling" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [tcpinc] CORRECTION: Reminder: Ongoing Working Group Last Call about drafts to choose as WG item
Date: Fri, Jul 24, 2015 11:17 AM

Dear all,

Here are the two drafts:

    July 31st, 2015
    1pm CEST

on wether you prefer
- either draft a) or b)

Regards,

   Martin Stiemerling
   Transport Area Director

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Jul 2015 12:20:00 +0200

On Mon, Jul 27, 2015 at 12:11 PM, Everhart, Craig <[email-masked]

>  (B) because I can use it, in a kernel (FreeBSD) environment, and I like
> its simple approach to authentication.  It provides a broader base of
> applicability--not just userspace connections.
>

In case it wasn't clear from the discussion in the meeting, TCP-use-TLS is
not restricted to
implementation in applications *or* in user-space. The implementation we
are developing
is a user-space daemon which intercepts outgoing and incoming packets, so
it will
cover unmodified applications, just as a kernel-level implementation would.

You could of course do a kernel-level implementation (indeed, I believe
Microsoft
has a kernel-mode SSL stack in their product), but that's not how we're
doing our
first cut.

-Ekr

Craig

---

From: Ted Hardie <[email-masked]>
Date: Mon, 27 Jul 2015 09:40:33 -0700

Since there was a request to restate viewpoints on the list even for those
of us vocal at the meeting, my current preference is for moving forward
with both, with an aim toward convergence if possible.

I think both provide a reasonable starting point, with the trade-offs
between the two being difficult to assess on an apples-to-apples basis
(simplicity versus re-use, to boil it down).  Given the lack of consensus
for either, I would prefer starting with both than continuing to block on
this decision.  Should consensus emerge to continue with either one, I will
support that consensus.

regards,

Ted

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 27 Jul 2015 10:23:21 -0700

Start with (b) tcpcrypt, and either adopt (a) once it is more specified or try to converge.

Part of this is pragmatic. If we end up with a protocol based on tcpcrypt, then we will probably want to have started working earlier since there is more content to review. Even if the drafts merge, to have more from TLS brought into tcpcrypt, the experience with working on tcpcrypt will be informative.

— Tommy

> On Jul 24, 2015, at 2:16 AM, Martin Stiemerling <[email-masked]> wrote:
> 
> 
> Dear all,
> 
> **Please use this CORRECTED version, as one option to choose from below didn't make it into the original.****
> This point got lost on the mailing list, but it has been decided in the WG session here at IETF-93 that there will be a Last Call for consensus about which document of the below ones to take as starting point for the WG.
> 
> 
> Here are the two drafts:
> Please note that accepting a draft is not the end of working on the technical content of the draft, but it is actually the starting point when the WG has full change control about the content of the draft!
> 
> 
> Regards,
> 
>  Martin Stiemerling
>  Transport Area Director
>

---

From: Brandon Williams <[email-masked]>
Date: Tue, 28 Jul 2015 00:30:42 -0400

I prefer adoption of A (tcpinc-tls-option), because:
* I believe a profile of tls can be produced that will be acceptable to 
kernel developers and can satisfy the "short, simple security proof" 
goal described by proponents of tcpcrypt, and
* I believe that a solution based on that profile of TLS is more likely 
to achieve the WG's stated goal of ubiquitous encryption, because it 
will be easier to deploy into many environments due to existing security 
and/or middlebox constraints.

That said, since my opinion is largely based on the assumption that an 
acceptable profile can/will be produced, if that isn't the case by 
Yokohama, I will be more inclined to accept either "adopt both" or 
"adopt tcpcrypt".

--Brandon Williams

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 28 Jul 2015 10:35:06 +0200

Greetings, all,

My opinion is close enough to Ted's for me to quote it:

> On 27 Jul 2015, at 18:40, Ted Hardie <[email-masked]> wrote:
> 
> Since there was a request to restate viewpoints on the list even for those of us vocal at the meeting, my current preference is for moving forward with both, with an aim toward convergence if possible.
> 
> I think both provide a reasonable starting point, with the trade-offs between the two being difficult to assess on an apples-to-apples basis (simplicity versus re-use, to boil it down).  Given the lack of consensus for either, I would prefer starting with both than continuing to block on this decision.  Should consensus emerge to continue with either one, I will support that consensus.

(in other words, adopt both with a view toward convergence within the WG process, support consensus around either as a starting point should it develop.)

No matter where we start, I believe a successful TCPINC protocol will have the following properties:

(1) plays very nicely with (D)TLS (1.x): TCPINC should be seen as a transitional technology, as a way to reduce the proportion of cleartext traffic on the Internet while application-layer protocols are redesigned and reimplemented with confidentiality in mind. Given that TLS is the default way to build security in now, this implies simple runtime upgrade to TLS is a necessary feature. We can have a discussion about which version to support this upgrade to -- since it's a transition technology to doing things right, we can target upgrade to / integration with a future (D)TLS version.

(A) plays very nicely with kernel TCP implementations: the requirements here are "minimal connection setup latency penalty" and "negligible steady-state throughput penalty given sufficient processing power and/or crypto acceleration", which currently implies relatively tight integration into the stack.

Cheers,

Brian

> regards,
> 
> Ted
> 
> 
> On Fri, Jul 24, 2015 at 2:16 AM, Martin Stiemerling <[email-masked]> wrote:
> 
> Dear all,
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Jul 2015 11:42:54 +0300

> On Jul 27, 2015, at 8:23 PM, Tommy Pauly <[email-masked]> wrote:
> 

Hi, Tommy

I’ll pick on you because you work for a major OS vendor and ultimately wide deployment requires implementation on Windows, Mac OS, iOS and Android (with all due respect to BSD).

Do you see one or the other as being more likely to get implemented?

Yoav

---

From: John-Mark Gurney <[email-masked]>
Date: Thu, 30 Jul 2015 16:47:55 -0700

> - both drafts (a & b) as WG items

I prefer draft b, tcpcrypt.

> when the WG has full change control about the content of the draft!

tcpcrypt has the experience of a working implementation, and did work
and research the impact on middleware boxes to ensure that it would
work.  It is also a concise and complete specification.

The TLS proposal also limits the ability to make modifications as
needed to achieve the goal of this WG if it continues to need to
interoperate w/ the TLS spec/WG.

The TLS proposal still allows for implementations to do a minimal
implementation where TLS is pushed down to userland.  This option
should not be allowed as vendors will implement this, and then claim
compliance to the RFC.   Requiring a userland
implementation/modification breaks a point that this WG requires:
"The protocol must be usable by unmodified applications.".  Any spec
that allows implementations to require userland modification should be
removed from consideration.

Thanks.

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

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 30 Jul 2015 18:58:30 -0600

I prefer for the WG to select draft a) draft-rescorla-tcpinc-tls-option-03 as the starting point.

The track record of security bugs in developing a new security protocol result in me having a strong preference for using something where lots of people have spent a lot of time looking at the algorithms. I think using TLS as a starting point will results in less problems than something new. 

It's been a long time since I wrote kernel code but I did the original code for the wireless networking in the Linux kernel. I don't buy the argument that one can not write TLS in the kernel. Many embedded systems (such as Cisco phones) already do TLS in the kernel.  Some of the ways that people do SSL based VPNs (like AnyConnect) also ends up with TLS in the kernel.

---

From: Kyle Rose <[email-masked]>
Date: Thu, 30 Jul 2015 21:25:38 -0400

I am in favor of pursuing both drafts, mostly because I think each
group has something to offer, and they are disparate-enough camps that
it's unlikely the tcpinc effort would be slowed by pursuing both.

IMO, tcpcrypt provides what we really need: a clean break with legacy
systems, a simple, easily-understood security primitive with provable
security properties, and a natural separation between
application-specific authentication and general-purpose encryption.
It's also basically ready-to-go, and so having it become
standards-track will quickly result in adoption by major Linux
distributions.

OTOH, TLS-the-brand is established and trusted by vendors, and so a
TLS-based proposal would likely gain wide acceptance more quickly
simply on that basis. Since the chief goal is to achieve universal
encryption, this is not a flippant justification.

While both proposals have pros and cons, either will fulfill the goals
of the WG.

(I just took a look at the TCP-ENO draft, and I propose we accept that
as well as the anticipated updated draft of tcpcrypt based on
TCP-ENO.)

Kyle

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Jul 2015 08:11:03 +0200

I think that Cullen said everything I intended to. See also Mark Twain when
it comes to eggs and baskets.

And then there is the part where I express confusion about this poll. The
working group seemed to have consensus on something else.
On Jul 31, 2015 2:58 AM, "Cullen Jennings" <[email-masked]> wrote:

> The track record of security bugs in developing a new security protocol
> result in me having a strong preference for using something where lots of
> people have spent a lot of time looking at the algorithms. I think using
> TLS as a starting point will results in less problems than something new.
>
> It's been a long time since I wrote kernel code but I did the original
> code for the wireless networking in the Linux kernel. I don't buy the
> argument that one can not write TLS in the kernel. Many embedded systems
> (such as Cisco phones) already do TLS in the kernel.  Some of the ways that
> people do SSL based VPNs (like AnyConnect) also ends up with TLS in the
> kernel.
>
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 31 Jul 2015 09:43:52 +0300

> On Jul 31, 2015, at 3:58 AM, Cullen Jennings <[email-masked]> wrote:
> 
> 

To be fair, the variant of TLS that is used tens of billions of times a day and has been analyzed heavily for almost 20 years is one where the server authenticates with a certificate. The ANON_DH or ANON_ECDH(E) variants of the protocol are hardly ever used.

> It's been a long time since I wrote kernel code but I did the original code for the wireless networking in the Linux kernel. I don't buy the argument that one can not write TLS in the kernel. Many…

Definitely. Our SSL VPN server as well as TLS proxy and portals do TLS in the kernel. Works fine.

Yoav

---

From: Pekka Riikonen <[email-masked]>
Date: Fri, 31 Jul 2015 09:05:22 +0200 (CEST)

> when the WG has full change control about the content of the draft!
Both drafts can work as the starting point and neither are yet good 
enough, but I vote for b) draft-bittau-tcpinc-tcpcrypt, because I believe 
it having the best chance to be morfed into a _simple_ protocol (simpler 
perhaps than with TLS).  Another reason is I fear using TLS makes the wait 
to get this out much longer as it depends on other WG.  Kernel vs user 
space arguments aren't really important and documents shouldn't be 
selected based on that (either can be implemented in kernel or user 
space).  There are many good reasons to vote for TLS and learn from it.

I vote for b) keeping in mind that once the work starts I would expect 
that the following be worked on:

  - Key exchange during TCP handshake (as such the new ENO draft is iffy)
  - Ability also for server side to start (attempt) tcpcrypt if client
    didn't

 	Pekka

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Jul 2015 11:23:40 +0200

I too am confused about this poll, since it seemed clear in Prague that we
had
consensus to provisionally move forward with both.

With that said, I prefer (a) draft-rescorla-tcpinc-tls-option-03, for the
reasons I
laid out previously: I believe it's a simple and direct application of TLS
to this
use case and that's better than having an entirely distinct protocol. It's
also
valuable to have a design which is a good fit for out-of-band negotiation
of application-layer TLS.

However, as I said in the meeting, I can live with the proposal to
provisionally
adopt both drafts and decide in November.

-Ekr

On Fri, Jul 31, 2015 at 8:11 AM, Martin Thomson <[email-masked]>
wrote:

> I think that Cullen said everything I intended to. See also Mark Twain
> when it comes to eggs and baskets.
>
>> I prefer for the WG to select draft a)
>> draft-rescorla-tcpinc-tls-option-03 as the starting point.
>>

---

From: Eric Smith <[email-masked]>
Date: Fri, 31 Jul 2015 02:38:41 -0700

I prefer:

DISCLAIMER: I am working on the tcpcrypt project and so am perhaps 
biased.  Reasons I support tcpcrypt include:
- simpler
- less dependence on other WGs or legacy standards/formats
- adds to the diversity of protocols
- more likely to make it into a kernel
- the Internet-Draft is more detailed
- running code

I also support the TCP-ENO draft (I am a co-author).

Thanks,
-Eric Smith

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 31 Jul 2015 11:38:29 +0100

As previously stated I think tcpcrypt is a better starting point
for tcpinc.

For those confused about this poll, I'm not sure if this will help
but when we hummed in the room about which document to start from,
and the chairs didn't see rough consensus in the room, they were
asked to confirm that lack of consensus on the list. I believe this
poll is just that - to confirm that we don't have rough consensus
for one or the other. Assuming we still lack rough consensus, then
the WG I guess starts down the road covered by all the later
discussion in the room about stuff to do between now and Nov (that
is IMO hugely likely to end in a coin-toss;-().

My justification for wanting to start from tcpcrypt is in the end
down to the additional genetic diversity that would result. I think
we'll end up with almost exactly the same functionality regardless of
the starting point we choose but that starting from tcpcrypt has the
benefit that we're less likely to get the same protocol or ciphersuite
or implementation problems in both TLS and TCPINC at the same time. For
me, that means that TCPINC-starting-from-tcpcrypt is more likely to be
a backup for TLS for when stuff hits the fan again, which I think is
something beneficial, as stuff will always eventually hit the fan.

Other than the genetic argument, I think most of the other arguments
for one or the other are not compelling. In particular, the "we've had
TLS for 20 years" one really does not apply here - TCPINC-starting-
from-TLS will be based on TLS1.3 which is brand new.

It is true that TLS1.3 will have a *lot* more expert eyeballs looking
at it over the coming year or two, but that is something that's mostly
still to happen, but has not yet happened. So while I think it is true
that starting from TLS will ensure better and deeper security analysis,
that is not something we already have by any means.

I also dislike the argument that tcpcrypt or TLS1.3 is new and
therefore more likely flawed. Since that argument applies equally to
both proposals, it is not useful for selecting a starting point.
And the IETF either is or is not able to design security protocols
well. If we can then we can do TCPINC based on either starting point.

If the IETF cannot design security protocols, then we should not be
doing TLS1.3. My belief is that we are far better now at designing
security protocols than we were 20 years ago, mainly due to the fact
they they are really widely used now, but then I would say that
wouldn't I:-)

Lastly, from a purely IETF process perspective I would also prefer to
not see TCPINC and TLS1.3 tightly coupled. Timing and personnel issues
like that can lead to delay and friction. I'd hope that'd not happen
here, but even if not, I think that TLS1.3 is so important right now,
that I would prefer to not see TCPINC affect that work at all. Starting
from tcpcrypt is better from that POV. (Note though, that this is a
really weak argument that's only worth mentioning if you believe as I
do that either proposal is ok as a starting point.)

Cheers,
S.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 31 Jul 2015 07:36:31 -0700

> that is not something we already have by any means.

No amount of expert review can make up for the harm of extra
complexity, and I feel there's an unusual amount of forbearance being
practiced to keep TLS in the running. We're being promised a simpler
profile, with no sign of one. We're promised a way this will interact
with traffic already TLS encrypted, with little explanation of why
tcpcrypts solution is inadequate.

Not all IETF protocols had equal security failures. SSH doesn't have
any of the negotiation issues TLS is plagued with, because it's
designed better. Plenty of TLS issues were identified and ignored,
even as chances to fix them passed. Neither of them correctly
understood symmetric key crypto when originally designed.

> well. If we can then we can do TCPINC based on either starting point.

The question isn't "can you design a security protocol": tcpcrypt is
already designed, and secure. Its "Can you refrain from screwing it
up?". If people think there are problems, find them.