I have only had a quick skim of the draft. Firstly, I think that this is the right sort of split to make if we hope to make progress here.
However, in my view, the design (and the draft) could be made considerably smaller and less complex. A simpler design would mimic ALPN. The initial SYN, would include a list of options. The SYN+ACK would contain the selected option. A single octet each should suffice for the option. tcpcrypt would need but a single codepoint, as would tcp-use-tls. The proposed design includes considerably more flexibility than needed. If a specific choice of encryption requires more information to be carried in option space, it can use another option. It also occurs to me that this could be made generic; encryption is - at a level of abstraction appropriate to this specification - just a stream filter on the connection. Maybe the same option could be used to enable other such things (compression springs to mind, though that is likely be a bad idea). On Jul 31, 2015 12:26 AM, "David Mazieres" < [email protected]> wrote: > The tcpcrypt team is as committed as ever to contributing to continued > improvement, standardization, and deployment of tcpcrypt should the > draft be adopted by the TCPINC working group. > > However, we have decided that it may be preferable to specify tcpcrypt > in two separate documents: one concerning the negotiation of > encryption, the other concerning key agreement and data transmission > formats. > > The downside of splitting the draft is that the previous document was > already in good shape and has essentially been more-or-less > "ready-to-go" for over a year (with periodic revisions to meet working > group decisions). If the working group decides to adopt the existing > tcpcrypt document tomorrow, we believe it would make a great starting > point for an RFC. Of course, once the working group assumes ownership > of the document, we anticipate continued improvements, which may > ultimately include splitting the document anyway. > > The upside of splitting the draft is twofold. First, throughout the > TCPINC process, we have heard of ongoing standardization efforts (such > as large options) that could benefit TCPINC. Unfortunately, those > technologies are not yet ready for deployment. Separating negotiation > from encryption leaves us maximum flexibility to evolve TCPINC to > exploit future TCP enhancements in a backward-compatible way. > > Second, we believe that the TCPINC working group has considerable > agreement on what needs to happen for encryption negotiation, and that > most of the disagreement has revolved around key agreement and wire > formats. It is our hope that if the working group can agree on a > negotiation mechanism, this will constitute concrete progress that can > inject momentum into the whole TCPINC standardization process. > > The new draft, called draft-bittau-tcpinc-tcpeno-00 (TCP-ENO), is > available at the following URL: > > https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpeno/ > > Unless people either strenuously object to this draft (or kill > tcpcrypt), we will shortly release an revised tcpcrypt draft built on > TCP-ENO. We encourage everyone who has not yet voted on this list to > vote to adopt tcpcrypt tomorrow. But now you can additionally vote to > adopt TCP-ENO. Even if you voted for TCP-use-TLS, I would encourage you > to consider voting for TCP-ENO as well, as those two drafts could also > be made to work together. > > My vote is to adopt both TCP-ENO and tcpcrypt, which together provide an > obvious path for harmonization. > > David > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
