Eric Rescorla <[email protected]> writes: > I don't think this follows at all. The charter doesn't say anything > about kernel implementations. It says "The protocol must be usable by > unmodified applications"...
> Another concrete scenario (which is attractive for a TLS > implementation) is to use a minimal kernel component (or a divert > socket) to do the ENO options with a modified libc to actually do the > TLS negotiation and data handling. This would also provide > system-wide support but would not be in the kernel. I don't see > anything in the charter which prohibits this. The libc implementation won't work with unmodified applications, because it will break when sharing/passing/inheriting file descriptors across processes, a common pattern for Unix servers. It will probably be best to take a two-pronged strategy, where a rock-solid user-level daemon implementation gets us deployment in places where people want to secure network storage protocols, database connections, etc. But then that adoption creates pressure to upstream the kernel implementation. My experience from tcpcrypt is that cloud providers are interested in the functionality but very skittish about any kernel mods. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
