netdev - Re: a question about the kcm proposal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Oct 2015 15:05:49 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	davejwatson@...com
Subject: 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html