I have read the draft, and I strongly support its adoption. This is exactly the sort of work that I believe that the working group can make progress on even as there is ongoing discussion of the key agreement and wire format.
There are a few places where I disagree with the draft's technical choices, but that is, in my opinion, a good reason to adopt it: it is already concrete enough to start discussing the technical details. Let's get it on board and get to work, regards, Ted On Thu, Jul 30, 2015 at 3:26 PM, 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
