Re: a question about the kcm proposal
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: a question about the kcm proposal
> > 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 > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
a question about the kcm proposal
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
