Subject: [tcpinc] the two proposals are much closer now, and could be even closer

From: Tim Shepard <[email-masked]>
Date: Fri, 27 Mar 2015 08:45:52 -0400

In my opinion what happened at tcpinc yesterday was a very good thing.

Before yesterday, the two proposals were architecturally different in
a way that mattered.    After yesterday, the proponents of one of the
two proposals have agreed to adopt the (implied) architecture of the
other proposal (have a TLV framing protocol within the byte stream
carried by TCP).

And I believe maybe, depending on how the WG decides to answer a few
more incremental questions, the proposals could move even closer
together.  Perhaps even so close together that they could interoperate
with each other.  And if we can get them that close together, should
we care about the remaining differences?

It seems to me the next question we should consider is what will be
the basic starting point for the framing format.  All we've heard so
far from one side is that it will be TLV.  The other side is already a
TLV protocol of sorts, perhaps a bit more complicated than we would
like.  But at this point we need to pick one.

In order to move the proposals even closer together, it might make
sense to pick the same framing format for both proposals.  And if we
pick as a starting point for the framing protocol implied by TLS's
framing, then we do the tweaks that Tero mentioned are needed to
handle some corner cases in TCP (work which would probably be pretty
much the same for both protocols), then the two proposals are even
closer together.

Then we just need to figure out the key exchange protocol and crypto
to be carried in this framing protocol.  If we can get the two sides
to agree on this, we achieve interoperability.  In the TLS case, I
believe it was mentioned that we would select a profile of TLS.  If
that profile of TLS results in something thin enough, then maybe it
would be amenable to being implemented in an elegant and clean library
that would be less objectionable to link into a kernel.

So then what we would be left with would be two different ways of
thinking about and implementing what is, on the wire, the same
protocol, with two different stories about what is going on.  But if
the two different kinds of implementation interoperate, then we don't
have to pick between them.  We can declare the resulting protocol
"tcpinc" and both can be deployed.   (And we'll have two different
implementations that interoprate!)

Any hope of the fantasy I've outlined above becoming reality?

			-Tim Shepard
			 [email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Mar 2015 12:49:38 -0500

TLS has a TLV format already.  Are you suggesting that tcpcrypt adopt that?

To be more precise, the TLS application data type is the three byte
sequence: 23, 3, 1.  The length is a two byte value that follows it.
Handshakes use the 3 byte sequence: 22, 3, 1.

On 27 March 2015 at 07:45, Tim Shepard <[email-masked]> wrote:
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc