On Thu, Oct 22, 2015 at 7:49 PM, David Mazieres < [email protected]> wrote:
> 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. > Hmm... I've seen designs where this should work, for instance where you dup the fds to point them to some intermediate location. -Ekr > 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
