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 protected]> wrote: > > > 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 protected] > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
