a question about the kcm proposal

a question about the kcm proposal

[Sowmini Varadhan]

Thinking back a bit about the kcm proposal:
 https://www.mail-archive.com/netdev@vger.kernel.org/msg78696.html
I had a question:

If the user-space  has decided to encrypt the http/2 header using tls,
the len (and other http/2 fields) is no longer in the clear for the kernel.

My understanding is that http header encryption is common practice/BCP,
since the http hdr may contain a lot of identity, session and tenancy data.
If that's true, then wouldn't this break the BPF/kcm assumptions? 

There is a different but related problem in this space- existing TLS/DTLS
libraries (openssl, gnutls etc) only know how to work with tcp
or udp sockets - they do not know anything about PF_RDS or the
newly proposed kcm socket type.

In theory, it is possible to extend these libraries to handle
RDS/kcm etc, but (as we found out with RDS and IP_PKTINFO/BINDTODEVICE),
some things become tricky because of the many-to-one dgram-over-stream
hybrid.

I've looked at  IPSEC/IKE in transport mode for RDS on the kernel tcp
socket as we discussed at Plumbers in August, and that has some costs..
would be interesting to evaluate against other options..

--Sowmini

Re: a question about the kcm proposal

[Tom Herbert]

>
> If the user-space  has decided to encrypt the http/2 header using tls,
> the len (and other http/2 fields) is no longer in the clear for the kernel.
>
> My understanding is that http header encryption is common practice/BCP,
> since the http hdr may contain a lot of identity, session and tenancy data.
> If that's true, then wouldn't this break the BPF/kcm assumptions?
>

Right, if data is encrypted then we can't do message delineation on
receive. KCM wouldn't help much on transmit either since the crypto
state would need to be shared. The solution is to move TLS into the
kernel.

> There is a different but related problem in this space- existing TLS/DTLS
> libraries (openssl, gnutls etc) only know how to work with tcp
> or udp sockets - they do not know anything about PF_RDS or the
> newly proposed kcm socket type.
>
TLS-in-kernel would be a lower layer so it shouldn't have to know
anything about RDS or KCM. If it makes sent KCM could be used for
parsing TLS records themselves...

> In theory, it is possible to extend these libraries to handle
> RDS/kcm etc, but (as we found out with RDS and IP_PKTINFO/BINDTODEVICE),
> some things become tricky because of the many-to-one dgram-over-stream
> hybrid.
>
> I've looked at  IPSEC/IKE in transport mode for RDS on the kernel tcp
> socket as we discussed at Plumbers in August, and that has some costs..
> would be interesting to evaluate against other options..
>
The design of TLS in the kernel is that it will be enabled on the TCP
socket, so that receive and transmit path are below RDS and KCM. We
have the transmit path for TLS-in-kernel running with good preliminary
results, we will post that at least as RFC shortly. Receive side still
seems to be feasible.

Thanks,
Tom

> --Sowmini
>
>

Re: a question about the kcm proposal

[Sowmini Varadhan]

On (10/12/15 15:05), Tom Herbert wrote:
> > There is a different but related problem in this space- existing TLS/DTLS
> > libraries (openssl, gnutls etc) only know how to work with tcp
> > or udp sockets - they do not know anything about PF_RDS or the
> > newly proposed kcm socket type.
> >
> TLS-in-kernel would be a lower layer so it shouldn't have to know
> anything about RDS or KCM. If it makes sent KCM could be used for
> parsing TLS records themselves...

I wouldn't quite jump to that conclusion just yet though :-)

there are a lot of alternatives- you could have a uspace module
that shims between the application and kcm (even something that gets
LD_PRELOADed) and adds the right kcm header as needed. Or you
could use ipsec/ike..

tls in the kernel can be quite complex and history shows that it
can easily become hard to maintain: uspace TLS (both the protocol itself,
and the negotiated crypto) tend to move much faster than kernel changes
(at least that's what the 10+ year long solaris-kssl experiment found).

There is another aspect to this: in the DB world, for example,
I might seriously care about encrypting my payroll-database, but not
care so much about the christmas-potluck-database. Thus allowing the
uspace to select when (and what type of crypto algo) to use is a flexibiility
offered by TLS that a "kernel-TLS" would have a hard time matching.

> The design of TLS in the kernel is that it will be enabled on the TCP
> socket, so that receive and transmit path are below RDS and KCM. We
> have the transmit path for TLS-in-kernel running with good preliminary
> results, we will post that at least as RFC shortly. Receive side still
> seems to be feasible.

yes, please share.

TLS does complex things like mid-session CCS. Such things can result
in a lot of asyncrony in the kernel. Given that ipsec has already crossed 
that bridge, I, for one, would like to understand the trade-offs.

The question in my mind,  is "how does this match up with 
transport mode ipsec/ike", and if it does not, why not? The only 
difference (in theory) is whether you do encryption before, or after,
adding the transport (tcp/udp) header, so if there is a big perf gap,
we need to understand why.

--Sowmini