netdev - Re: [PATCH v2 2/3] net/handshake: Add support for PF

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:   Thu, 2 Feb 2023 12:13:26 -0500
From:   Xin Long <lucien.xin@...il.com>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     Hannes Reinecke <hare@...e.de>, Jakub Kicinski <kuba@...nel.org>,
        Chuck Lever <chuck.lever@...cle.com>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        hare@...e.com, dhowells@...hat.com, kolga@...app.com,
        jmeneghi@...hat.com, bcodding@...hat.com, jlayton@...hat.com
Subject: Re: [PATCH v2 2/3] net/handshake: Add support for PF_HANDSHAKE

On Tue, Jan 31, 2023 at 9:24 AM Marcel Holtmann <marcel@...tmann.org> wrote:
>
> I know, utilizing existing TLS libraries is a pain if you don’t do
> exactly what they had in mind. I started looking at QUIC a while
> back and quickly realized, I have to start looking at TLS 1.3 first.
>
> My past experience with GnuTLS and OpenSSL have been bad and that is
> why iwd (our WiFi daemon) has its own TLS implementation utilizing
> AF_ALG and keyctl.
Hi Marcel,

I'm no expert on TLS, but I'm a supporter of in-kernel TLS 1.3 Handshake
implementation :). When working on implementing in-kernel QUIC protocol,
the code looks a lot simpler with the pure in-kernel TLS 1.3 Handshake APIs
than the upcall method, and I believe the NFS over TLS 1.3 in kernel will
feel the same.

>
> While that might have been true in the past and with TLS 1.2 and earlier,
> I am not sure that is all true today.
>
> Lets assume we start with TLS 1.3 and don’t have backwards compatibility
> with TLS 1.2 and earlier. And for now we don’t worry about Middleboxes
> compatibility mode since you don’t have to for all the modern protocols
> that utilize just the TLS 1.3 handshake like QUIC.
>
> Now the key derivation is just choosing 1 out of 5 ciphers and using
> its associated hash algorithm to derive the keys. This is all present
> functionality in the kernel and so well tested that it doesn’t worry
> me at all. We also have a separate RFC with just sample data so you
> can check your derivation functionality. Especially if you check it
> against AEAD encrypted sample data, any mistake is fatal.
>
> The shared key portion is just ECDHE or DHE and you either end up with
> x25519 or secp256r1 and both are in the kernel. Bluetooth has been
> using secp256r1 inside the kernel for many years now. We all know how
> to handle and verify public keys from secp256r1 and neat part is that
> it would be also offloaded to hardware if needed. So the private key
> doesn’t need to stay even in kernel memory.
>
> So dealing with generating your key material for your cipher is really
> simple and similar things have been done for Bluetooth for a long
> time now. And it looks like NVMe is also utilizing KPP as of today.
>
> The tricky part is the authentication portion of TLS utilizing
> certificates. That part is complicated, but then again, we already
> decided the kernel needs to handle certificates for various places
> and you have to assume that it is fairly secure.
>
> Now, you need to secure the handshake protocol like any other protocol
> and the only difference is that it will lead to key material and
> does authentication with certificates. All of it, the kernel already
> does in one form or another.
>
> The TLS 1.3 spec is also really nicely written and explicit in
> error behavior in case of attempts to attack the protocol. While
> implementing my TLS 1.3 only prototype I have been positively
> surprised on how clean it is. I personally think they went over
> board with the key verification, but so be it.
>
> Once I have cleaned up my TLS 1.3 prototype, I am happy to take
> a stab at a kernel version.
>
I'm glad to hear that you're planning to add this in kernel space, and I
agree that there won't be a lot of things to do in kernel due to the kernel
crypto APIs. There is also a TLS 1.3 Handshake prototype I worked on and
based on the torvalds/linux kernel code. In case of any duplicate work
when you're doing it, I just share my code here:

  https://github.com/lxin/tls_hs/blob/master/crypto/tls_hs.c

and the TLS_HS APIs docs for QUIC and NFS use are here:

  https://github.com/lxin/tls_hs

Hopefully, it will help.

Besides, There were some security concerns from others for which I didn't
continue:

  https://github.com/lxin/tls_hs#the-security-issues

It will be great if we can have your opinions about it.

Thanks.