On Mon, Aug 01, 2011 at 10:25:14AM -0700, David A. McGrew wrote: > This sounds like an option worth pursuing, no pun intended. You > make good points about why TCP is a good place to do the capability > discovery and fallback for crypto. Why not define a TCP option > that can enable devices to discover TLS or tcpcrypt or other > higher-layer crypto protocols? That option would be much easier to > implement and standardize, and it could tie into a full tcpcrypt > protocol that resides in a shim above the TCP layer. The separation > will create useful implementation alternatives, and will isolate the > TCP state machine from changes.
We have been considering this option throughout the work (and will still do) but: * No TCP header protection. TCP-AO, which you suggest, does not interoperate with NATs. We want something that works "out of the box". * We can't leverage the 3-way handshake if operating at the application layer. With tcpcrypt, we can do all session key negotiation in a 4-way handshake (just one extra leg), or 3 if session caching. Saving RTTs seems like a good thing. >From a clean-slate perspective, it seems that integrating this into TCP has all the advantages we're looking for. Doing minimal work at TCP (like a signle "do you crypto?" option) and doing the rest at an application layer seems to come at a compromise (e.g., the drawbacks listed above). >From an implementation perspective, I agree that the least changes to TCP are probably the best option. tcpcrypt, at least for us, seems to have a good balance between clean-slate and (relatively) few changes to TCP, hence why we're pushing for it, as is. If there were non-implementation arguments as to app vs. transport layer we'd love to hear those.
