Message-ID: <54cf4728-de7b-5774-5e92-7c30a678e346@suse.de>
Date:   Wed, 1 Feb 2023 08:09:45 +0100
From:   Hannes Reinecke <hare@...e.de>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     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 1/31/23 21:32, Marcel Holtmann wrote:
> Hi Hannes,
> 
[ .. ]
>>> It is just painful for the simple reason that there is no real
>>> standard around CA certificates and where to place them. Every
>>> distro is kinda doing it their way and you expect your TLS
>>> library to do the magic.
>>> I like to see systemd create a keyring of the CA certs, seal it
>>> and then provide it do every process/service it launches. And
>>> for non systemd distros they need to find a way to actually
>>> provide that one keyring that can be used as master for all the
>>> CA certs.
>>> We have not bothered with that yet since for WiFi, you always
>>> have a client cert derived from the CA of the server. So you
>>> give a CA cert and a client cert when you connect to WiFi
>>> Enterprise systems.
>> The good thing is that NVMe is currently PSK-only, so the certificate
> bit is easy for me. Others like NFS will have to do proper X.509 cert
> handling, but I'll let them worry about that :-)
> 
> Interesting. I have not looked at PSK part yet. Do you require PSK-only
> or ECDHE+PSK. From what I quickly glanced at the spec, the PSK-only is
> really simple. That is the most simplest TLS Handshake I have seen and
> I should give that a spin.
> 

ECDHE+PSK, sadly; the PSK-only method will be deprecated eventually.
But I've got code for that already, so that's nothing to worry about.

> So NVMe agrees the PSK out-of-band? I might be able to read up on it,
> but I can only keep so much specifications in memory ;)
> 
Yep, that's the plan. Or, one could say, the 'P' in PSK :-)
That's where keyrings come in; idea is that external agent populate the 
keyring, and the kernel code just looks up keys from there.

[ .. ]
>>>> And that was the other thing; we found quite some TLS implementations,
>>>> but nearly all of the said '1.3 support to come' ...
>>> True to that. I think even OpenSSL started an effort to have a
>>> QUIC specific API now.
>>> The problem that I found is that TLS Handshake, TLS Alert and
>>> TLS Record protocol are not cleanly separated. They are mixed
>>> together.
>> Yep.
>>
>>> For example if I want to use kTLS, I mostly just have to deal
>>> with TLS Handshake portion. QUIC was specific and just uses
>>> TLS Handshake and TLS Alert are converted to QUIC errors.
>> Some for us. Alerts don't make sense to us as we have long-lived
>> connections, so the prime reason for alerts is gone, and we have
>> to re-establish the connection whenever the cipher is changed. So
>> we will be converting alerts in errors, too.
> 
> What is the solution for sequence number exhaustion. Do you
> re-connect or do you re-key via TLS?
> 
Reconnect. We don't have a good way of allowing for re-keying, as the
key material directly relates to information retrieved from the protocol 
itself (here: the TLS key might derived from the DH-CHAP authentication 
protocol running in NVMe space).
So for any re-key operationn we'll should to re-run that protocol. At 
which point we might as well kill the connection and start over, as this 
is basically the same operation.

[ .. ]
>>>>> Long story short, who is suppose to 
>>> And I am certain that Wireshark would love to get hold of
>>> the unencrypted TLS Handshake traffic. Debugging TLS
>>> and also QUIC transfers is hugely painful. The method of
>>> SSLKEYLOGFILE works but it is so cumbersome and defeats
>>> any kind of live traffic analysis. So having some DIAG
>>> here would help a lot of developers.
>> Oh, yes. That would be nice side-effect.
>>
>> So, when can I expect the patch?
>> :-)
> 
> Lol. I need to get a few things cleaned up in the userspace
> prototype I have. Then I take a stab at a kernel code. I do
> need to build myself a test setup for PSK-only since I have
> not yet bothered with that.
> 
I'd be happy to have the userspace code; my plan is to work on a frame 
forwarder (such that the TLS handshake and alert frames are forwarded to 
userspace via netlink).
Then I can repurpose the daemon code from the accept solution to handle 
those netlink frames, and use your library for the tls handshake.

That would give us a nice proof of concept, and if designed properly the 
frame forwarder could later be modified to redirect to the in-kernel code.

So having the userspace code already is a bonus.
And the 'patch' really was just for the userspace library :-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@...e.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman

Powered by blists - more mailing lists