Subject: [tcpinc] Developer opinions matter

From: Watson Ladd <[email-masked]>
Date: Thu, 23 Jul 2015 07:32:45 -0700

Dear all,

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.

Sincerely,
Watson Ladd

---

From: John-Mark Gurney <[email-masked]>
Date: Thu, 23 Jul 2015 10:50:28 -0700

> 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."

---

From: Thomas Daede <[email-masked]>
Date: Fri, 24 Jul 2015 00:19:32 +0200

> validating X.509 certificates.

Well, the Linux kernel already has an X.509 parser :)

Doing the handshake in userland is an option for a TCP-TLS
implementation, however I think the overhead of that approach will cause
most distros to leave it off by default.

> code was written from the start to be used in the kernel.

This is true for Linux as well. No existing TLS implementation is
available that is suitable for inclusion in the kernel. I would expect
an implementation to be an entirely new TLS codebase.

Maybe I have missed it, but has there been a thread on the LKML about
this yet?

Thomas

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 24 Jul 2015 07:57:43 +0000

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-masked]> wrote:
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Jul 2015 10:22:58 +0200

> > validating X.509 certificates.

There's not going to be any need to do either of these. I'm working on
the profile, but expect it to be anonymous (EC)DHE, and so not
require certificates.

> We have one under development and expect to have something available
by Yokohama, as discussed in the WG meeting on Monday.

-Ekr

---

From: John-Mark Gurney <[email-masked]>
Date: Fri, 24 Jul 2015 10:59:23 -0700

> the profile, but expect it to be anonymous (EC)DHE, and so not

Well, require and support are two different things.  Under chapter 10,
you say:
If some sort of external authentication mechanism was provided or certificates are used

This implies that certificates may be used.  What is going to happen
if one side decides to require a certificate and the otherside rejects
any certificate use?  Then we end up again, back to an unencrypted
session, or worse (better?), failure to establish the session.

I do realize that ladder diagram does not even mention the Certificate
side of things, so probably the clause, "or certificates", should just
be removed.

It should be tightened up to explicitly disallow any use of
certificates, or at a minimum, that the side that presents a
certificate but does not receive a correct response, must continue as
if the certificate was ignored.

> by Yokohama, as discussed in the WG meeting on Monday.

It would be good if announcements of meetings were sent to the list.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Jul 2015 20:05:31 +0200

> if the certificate was ignored.

Thanks for your comments.

My thinking here is that I would like this mechanism to serve two purposes:

1. To allow for encryption in TCP at the system/kernel level.
2. To let applications discover when TLS is available and upgrade to it

In the former case, certificates are not useful but in the latter they are.

Perhaps what's needed is an indication in the initial extension handshake
of the expectation vis-a-vis authentication

-Ekr

---

From: John-Mark Gurney <[email-masked]>
Date: Fri, 24 Jul 2015 11:26:24 -0700

> of the expectation vis-a-vis authentication

This make sense, but...

The spec needs to be explicit that an conforming implementation needs
to implement the kernel side, and that simply allowing userland hand
off is not an acceptable.  The lack of this requirement worries me
that not enough focuse in this spec is put on making sure that all
deployments of this sepc will achive the goal of allways on
transparent encryption.

---

From: ianG <[email-masked]>
Date: Fri, 24 Jul 2015 19:49:21 +0100

> into the kernel. The fact that tcpcrypt is substantially simpler

I am also surprised that people think bolting TLS into the kernel will 
be received without comment.

I haven't touched a kernel in decades, and my knowledge of TLS is rusty 
at best.  But if I was a kernel dev, I'd simply say no.  Handoff to 
outside the kernel?  A non-starter.  Pulling any code base with the rep 
of OpenSSL into the kernel?  Are you crazy?  You want to write a new TLS 
code base that is good this time?  Come back when you've done it :D

The only thing that would make any sense is a small, tight protocol that 
did precisely what is required, and no more.  If it lacks a feature, 
tough.  You get what you get.  Want more?  Get some TLS at the 
application level.

And even that is a tough ask - getting that tight protocol into the 
kernels is going to require some serious work & consensus & TLC with the 
*BSD and Linux crowd.  Before we've even considered MS, Apple, Android, 
etc.  Then there are the router guys.  IoT.  National 
standards/anticrypto groups.

In this environment, only "simple" will survive.  Otherwise it's another 
ipv6 or IPSec "kitchen sink" approach which will face so much downstream 
resistance it will bog down somewhere or other.

> kernel layer solution that everyone can deploy and integrate.

Yep.  If they wanted to opt in, there's always TLS.  Nobody's taking 
that away from them.

The only good reason to put TLS in is crypto experience.  "Re-use."  But 
that's a theoretical reason.  This is not a theoretical project, it's an 
intensely practical one.  It won't make or break in an IETF WG.  It will 
make or break in *BSD / Linux kernels.  It is their consensus that 
matters, not the consensus here.

All, IMNSHO.

iang

---

From: Watson Ladd <[email-masked]>
Date: Fri, 24 Jul 2015 12:15:19 -0700

> 2. To let applications discover when TLS is available and upgrade to it

What was wrong with the tcpcrypt approach of letting applications discover
when the connection was encrypted already, and using X509 authentication
over that?

Let me broaden this: what features is tcpcrypt as it stands now not going
to provide that we need?