Re: [tcpinc] Quick review of draft-rescorla-tcpinc-tls-option-04

[Eric Rescorla <[e-mail]>]

On Thu, Oct 22, 2015 at 7:49 PM, David Mazieres <
[e-mail]> wrote:

> Eric Rescorla <[e-mail]> 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
>