> A->B: SYN "Hey, I support tcpcrypt and TLS" > B->A: SYN "Hey, I support tcpcrypt" > A->B: ACK(+) "Great, let's use tcpcrypt with cipher suite X or Y" > B->A: ACK(+) "Great, let's use tcpcrypt with cipher suite Z" > A->B: ACK(*) DH parameter, etc.
One way to resolve this for TLS is to just make TLS one of the cipher suites: A->B: SYN "Hey, I support (TLS, tcpcryptX, tcpcryptY)" B->A: SYN "Hey, I support (TLS)" A->B: ACK "Great, let's use TLS" B->A: ACK "Great, let's use TLS" And then switch to straight-up TLS, whether in userspace or in the kernel. In userspace this is a little tricky in that a software or administrative change to the cipher suite preference list should be made when TCP-ENO is activated by default in the kernel: as long as one of the two endpoints is properly configured, tcpcrypt-unaware endpoints will do the right thing, but if both endpoints are improperly configured you'll get two key exchanges and connections will be doubly-encrypted. (An HTTPS server implementor might just choose to turn off TCP-ENO for port 443, which would have the desired effect.) For passive/active, the same basic logic applies: A->B: SYN "Hey, I support (TLS, tcpcryptX, tcpcryptY)" B->A: SYN-ACK "Great, let's use TLS" B->A: ACK "Ok, let's use TLS" Kyle _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
