> We would like to ask the WG to express their support to adopt one (or > none) of the following documents as WG document that will serve as a > basis for the protocol specification. Of course, the draft, if adopted, > will need to updated according to the WG input. In particular, they > need > to be updated to not protect the TCP header. > > > The candidate drafts are: > > https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpcrypt/
My view is that this document has to change significantly before we can discuss adoption. Since this proposal significantly modifies the TCP protocol and the TCP state engine, I'd really prefer to *first* have a consistent document and *then* discuss a potential adoption. If the consensus in TCPINC is not to use header protection, I think header protection has to be removed entirely from the protocol specification - it could go to a separate document. I've stated already multiple times that I am really concerned about the definition of an own option payload encoding for INIT1 and INIT2 [1]. TCPM has a chartered milestone for EDO to provide long options. To me, EDO provides what is needed for INIT1/INIT2. If I miss something here, I am really willing to learn more. I do not think that the TCPINC working group should define a second and incompatible TCP long option format. This will very likely result in incompatibility issues once EDO, TCPINC, and/or other TCP extensions evolve in the future, or if they will be used in combination. The last thing we need in the IETF is standardizing multiple incompatible TCP variants each defining their own encoding of the data stream. This will end up in a mess. I believe updating draft-bittau-tcpinc-tcpcrypt to use EDO would only be a small change of the protocol. If EDO as currently defined was not sufficient for TCPINC, the TCPM working group would be really open to feedback [2]. Supporting combinations of TCP-AO, MPTCP, TCPINC, etc. was the main reason why TCPM decided to start the design of a long option solution. I also expect that a TCPINC protocol will (hopefully) evolve in future, and the TCPINC community should therefore develop a future-proof design. I imagine that future TCPINC enhancements could need the exchange of additional data, possibly exceeding the 40B option limit like INIT1/INIT2. In this case, a TCPINC protocol using the current tcpcrypt payload encoding could easily require further, very complex long option encoding hacks to be able to transport the data needed by such TCPINC extensions. As a result, I believe that the current INIT1/INIT2 encoding is not future-proof and may prevent an evolution of the TCPINC protocol itself. Again, if I should miss something here, I am willing to learn more. I am not a crypto algorithm expert. But without the need to offer TCP header protection, I assume that the unauthenticated encryption features of tcpcrypt can also be provided by a TLV encoding (or something equivalent) inside the TCP data stream. I'd assume that the actual protocol inside the TCP byte stream could be different to TLS if diversity was an important design objective - this part of the design has to be sorted out by security experts. In addition to a much cleaner protocol architecture not interfering with other TCP extensions, such a TCPINC design would also waste less scarce TCP option space and seems clearly superior to the current design in draft-bittau-tcpinc-tcpcrypt. To make the long story short: Do *not* adopt draft-bittau-tcpinc-tcpcrypt until a new version of the draft either uses EDO or until the specification defines a future-proof encoding. I am willing to review whether future updates of draft-bittau-tcpinc-tcpcrypt incorporate these changes prior to a potential adoption (if the TCPINC community decides to use this design as a basis). Thanks Michael [1] http://www.ietf.org/mail-archive/web/tcpinc/current/msg00370.html [2] http://www.ietf.org/mail-archive/web/tcpinc/current/msg00447.html > https://datatracker.ietf.org/doc/draft-rescorla-tcpinc-tls-option/ > > We plan to discuss this on the meeting but it would be useful to start > the discussion before the meeting, so if you can express your opinions > before the meeting, it would be helpful. > > Regards, marcelo (on behalf of the co chairs) > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
