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
