[PATCH 1/1] libnvme: TLS PSK derivation fixes

[Chris Leech]

On Fri, Jul 25, 2025 at 11:36:20AM +0200, Hannes Reinecke wrote:
> On 7/21/25 17:31, Chris Leech wrote:
> > On Mon, Jul 21, 2025 at 08:36:01AM +0200, Hannes Reinecke wrote:
> > > On 7/21/25 04:17, Chris Leech wrote:
> > > > There are issues with the Retained and TLS PSK derivations due to the
> > > > implementation not adhering to the RFC 8446 definition of the
> > > > HKDF-Expand-Label function.
> > > > ...
> > > Hmm. I _thought_ we had it all fixed...
> > 
> > I went into this expecting/hoping to find the problem on the spdk side,
> > and I'd be happy to wrong here (especially if backed up by another
> > interoperable implementor).
> > 
> > The lack of a full example in the nvme/tcp transport spec to verify
> > implemenatations against is kind of a bummer.
> > 
> Okay, seems that you have been right after all.
> I've re-read RFC 8466 and indeed you seem to be right about
> the encoding of variable length vectors (cf RFC 8446 section 3.4).
> 
> So I guess we need to take this patch after all.

So we're back to agreeing on the correctness of the changes?
Honestly, I appreciate the scrutiny.
 
> _However_: PSKs generated with after applying this patch will be
> different than those prior to this patch.
> Consequently there will be interop issues with existing implementations
> (which will use the original encoding).
> 
> I guess we would need to wait for the target implementations to be fixed
> or introduce a flag switching to the old / compat implementation to avoid
> interop issues.

Yes, it is a breaking change for compatibility with other out-of-spec
implementations.  I'm hesitant to carry a flag for that, but it wouldn't
be too much trouble to implement.

Just don't touch your keyfile?  The tls-key import/export commands are
operating on the final derived TLS PSKs right?

- Chris