Tero Kivinen <[email protected]> writes: > Daniel Kahn Gillmor writes: >> On 07/29/2014 07:36 AM, Tero Kivinen wrote: >> > Martin Thomson writes: >> >> >> 4. Able to access peer authentication credentials (often in >> >> combination with 3) > > I do not think there is any misunderstanding there. As I said in my > text the tcpcrypt does not offer authentication credentials as it does > not do authentication. It can provide the session ID, but that was > covered by the item 5 in the list, not by this item.
For the record, I agree with this and would argue against putting 4 in the list. The notion of authentication credentials is a slippery one that can quickly get into territory requiring pretty complex transport-layer configuration, which we would like to avoid. Layer-4 security should be like congestion control. It's there and for the most part it just works and there are only very minor tweaks (like buffer sizes, enable/disable Nagle, etc., or in tcpinc's case maybe prioritization among a very small number of cipher suites). Once you get into loading certificates and human-readable names and such into your sockets, you're getting into territory that is better served by existing TLS infrastructure, because the human-readable names come from the application and require application-level modification anyway. We are going primarily for opportunistic encryption, yet it would be a crying shame to go through all the trouble of standardizing something like this without supporting connection authentication for when it's useful in the future. That argues for the most minimal and flexible hook to accommodate whatever authentication needs arise, especially needs that are not already well served by the TLS infrastructure. (Meaning even with the TLS-use-TCP proposal, exposing simple channel bindings is going to be a lot more useful than duplicating a whole SSL API at the kernel level, because applications programmed to that interface could just link against an SSL library.) >> So I think "no way to do authentication" is not an accurate way to >> describe what tcpcrypt offers. > > It is accurate. Tcpcrypt does not do any of those as it is specified > now. Those things can be done by the application by accessing the > session id (item 5 in the list) and doing authentication in the > application, but outside the tcpcrypt. Exactly. Tcpcrypt's authentication support consists of two things: the session ID and the application-supported bit. We argue this interface is minimal but also very general. For example, our paper describes how we built a drop-in replacement openssl shared library that used tcpcrypt when both sides had the library, used SSL otherwise, and always disabled double encryption. (This isn't a compelling use case for tcpinc, other than benchmarking, since openssl works just fine as is, but it's a good demonstration of the generality of this simple API, which also facilitates many authentication schemes not in common use with TLS.) David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
