[Without any hats] marcelo bagnulo braun writes: > 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. > > https://datatracker.ietf.org/doc/draft-rescorla-tcpinc-tls-option/
I personally would prefer TLS option, mostly because: - Doing full security analysis for completely new key exchange protocol (tcpcrypt) will take time and effort, and we seem to be missing people having enough time in WG. Using existing already analysed protocol (tls) would make us able to go forward faster. Designing key exchange protocol is not that hard, but desining it so that it does not have any security issues is extremely hard as we have seen from our previous examples... - Using as little of TCP options, as possible, will provide us best possible way of getting through almost all possible middleboxes. Using separate framing (in TLS case the TLS record layer) inside the TCP stream and moving protection there, makes things to work through middleboxes. I.e. if we go with tcpcrypt, I would think that it would also benefit from this architectural change. - Regardless which solution we pick, implementing it in kernel will mean that new code needs to be written, I do not expect that people will be trying to run OpenSSL inside the kernel and be done with that. In that case I do not see that big difference whether we implement tcpinc tcpcrypt or whether we implement tcpinc TLS. We can limit features away which we do not need to make it small (for example if we start with one anonymous Diffie-Hellman ciphersuite, we do not need PKIX certificates etc). On the other hand the TLS already have existing code which can be used for testing (i.e. we can test our kernel space tcpinc TLS implementation against TLS test suites or implementations we already have), and also TLS do have lots of stuff already specified, which means that if we want to expand it to do some feature (for example raw key based authentication), we already have specifications for that, we just need to lift the restriction set in tcpinc specification and allow that to be used. -- [email protected] _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
