Subject: Re: [tcpinc] TCPINC - security protocols

From: "Black, David" <[email-masked]>
Date: Tue, 1 Mar 2016 20:00:01 +0000

Hmm ... I might suggest consulting the TLS 1.3 draft's version history:

https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-1.2

There are significant changes to the initial handshake from TLS 1.2, and
that initial handshake is the primary focus of the tcpinc profile of TLS.

Thanks, --David

> -----Original Message-----
> From: Tcpinc [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Monday, February 29, 2016 7:31 PM
> To: Derek Fawcus; tcpinc ([email-masked])
> Cc: [email-masked]
> Subject: Re: [tcpinc] TCPINC - security protocols
> 
> 
> 
> 
> > Black, David wrote:
> > While the TLS WG is hard at work on TLS 1.3, that protocol is not finished
> > yet; the chairs believe that completion of that base protocol is a necessary
> > prerequisite for a TCPINC profile of TLS 1.3 (e.g., as a TCPINC profile will
> > have to normatively reference the TLS 1.3 specification).  In addition,
> > from a broader IETF perspective, completion of TLS 1.3 really does need
> > to be the first priority for TLS experts such as Eric Rescorla.
> 
> Sorry if this has been asked (I didn't see it), but is this merely a
> person-cycles issue or is there some deeper reason for not designing it
> agnostic to 1.2 vs. 1.3 and requiring 1.2 support until 1.3 is ready?
> 
> Joe
> 
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: David Mazieres <[email-masked]>
Date: Wed, 02 Mar 2016 00:31:43 -0800

We've uploaded a new informational draft for the TCP-ENO proposed
interface extensions.  This draft incorporates the feedback we received
at the last meeting and afterwards.  Specifically:

 * There is now a separate default setting for active and passive
   connections.

 * There are new socket options TCP_ENO_LOCAL_NAME and TCP_ENO_PEER_NAME
   that concatenate the role and session ID.

 * There are more tables summarizing information, to present it more
   systematically.

 * The document provides guidance on what errnos to return, to encourage
   consistency across implementations.

 * The discussion of STUN-like path-checking servers has been split off
   into a separate "best current practices" document (which will be
   uploaded as soon as the API reference updates on xml2rfc).

The draft is available here:

        https://datatracker.ietf.org/doc/draft-bittau-tcpinc-api/

David

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 3 Mar 2016 09:51:43 +0100

Hi Joe,

yes, the 0-RTT handshake in TLS1.3 is the part that is most important for us and a requirement for tcpinc. Further there is no need for us to be backward compatible, as there are currently no tcpinc implementation that support a lower version. So that limits (implementation) complexity.

Mirja

> Am 01.03.2016 um 21:00 schrieb Black, David <[email-masked]>:
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 3 Mar 2016 09:38:08 -0800

Thanks - that's much more specific than the original posted reason.

Joe

---

From: David Mazieres <[email-masked]>
Date: Thu, 03 Mar 2016 11:06:57 -0800

>    uploaded as soon as the API reference updates on xml2rfc).

Just to follow up, the document is here:

        https://datatracker.ietf.org/doc/draft-bittau-tcpinc-bcp/

For the moment, this is mostly a placeholder document.  We would really
like to recruit some coauthors--particularly ones who have experience
with middleboxes traversal issues.  Please let us know if you might be
willing to contribute to this document (which need not keep any of its
existing content if you don't like it).

Thanks,
David

---

From: ianG <[email-masked]>
Date: Sun, 20 Mar 2016 23:27:14 +0000

On 29/02/2016 16:30 pm, Black, David wrote:
> For these reasons, the chairs strongly suggest that the best course of action
> for the TCPINC WG is to move forward to standardize tcpcrypt and TCP-ENO,

+1 on tcpcrypt!

iang