Hi all, writing as an individual contributor not as chair.
I’ve been think about these two use cases we’ve been taking about and though why don’t we support the two uses with the two different approaches. The two uses are: 1) The application is not tcpinc-aware and we want to provide opportunistic encryption. 2) The application implements TLS (1.3) and is tcpinc-aware and wants to use tcpinc/tcp-eno to negotiate TLS support with the other end. Now want we can do is to use tcpcrypt as the encryption solution within tcpinc but also provide an interface where the application can say that it implements TLS and signal this in the tcp handshake to the other end. This leads to the following three cases: 1) None of the ends have indicated that they implement TLS, therefore tcpcrypt is used. I guess in this case it doesn’t matter if we use tcpcryt or TLS on the wire. Might even be an advantage if it does not look like something know. And tcpcrypt is nicely integrated with tcp and might therefore be easier or at least more straight forward to also implement in there kernel. Btw. as a side note: in this case both ends are not tcpinc-aware, this might not mean that they do not implement TLS and negotiate it. Probably we should detect this case to not double-encrypt. 2) One end implements TLS and tcpinc signals this support but the other does not. Thus in this case we still would have to use tcpycryt, while a TLS-only solution would in this case allow the app to use TLS. Thus here is a difference. But as tcpinc is anyway rather a transition technology, that might be an real issue. 3) And, of course, if both ends implement TLS and indicate this, the TLS implementation of the application is used and we simply have a nice way to negotiate TLS support in the tcp handshake. Even though that’s not spelled out in our charter, I think that's a nice use case for tcp-eno and we should support this case in any case. Just my 2c. Let me know if that makes any sense to you! Mirja _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
