On Fri, Aug 1, 2014 at 9:16 AM, David Mazieres < [email protected]> wrote:
> 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.) FWIW, I generally agree with this. If you are an application that wants to use TLS and have fine control, you would be better off with the mostly out-of-kernel version of TCP-use-TLS than the all in-kernel version. -Ekr > >> 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 >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
