Nobody will be surprised that I fully agree here. NetApp has both FreeBSD and Linux based products, FWIW.
Lars On 2015-7-23, at 19:50, John-Mark Gurney <[email protected]> wrote: > > Watson Ladd wrote this message on Thu, Jul 23, 2015 at 07:32 -0700: >> I'm surprised more weight isn't being given to kernel developers who >> don't feel that TLS implementations are of sufficient quality to go >> into the kernel. The fact that tcpcrypt is substantially simpler >> matters considerably. >> >> The whole point of tcp encryption is that application authors do not >> have to opt-in. They have had years to do so and haven't. We need a >> kernel layer solution that everyone can deploy and integrate. > > I agree... > > I'm worried by all this additional talk about doing authentication > of the channel in the kernel... > > I've been working on project to accelerate TLS by doing the framing > and encryption work in the kernel, and not in userland. We made the > choice of not moving the handshake and certificate validation into > the kernel due to it's complexity and high risk for bugs. Yes, > tcpcrypt will have slightly more code than just framing and encryption, > but it's vastly more simple than doing anything wrt parsing and > validating X.509 certificates. > > If the TCP-TLS implementation is choosen, it will be significantly > longer before it will be integrated into FreeBSD. The reasons being > is that there is no code that can simply be used w/o major auditing > and/or rewriting to be secure for use in the kernel. The tcpcrypt > code was written from the start to be used in the kernel. > > Is there an implementation of TCP-TLS available yet? > > I've not seen this discussed, but why is it even an option to allow > the negotiation, but require userland to do TLS? IMO, this should > not be allowed. It virtually gurantees that encryption will not be > adopted, as most major OS vendors will implement this option, and > then the point of this exercise is fruitless. > > In fact, I don't see how an OS vendor could justify the increased > risk in implementing TLS in the kernel if such an option even exists. > > This option seems to go against the, no code modification needed > to support encryption. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
