From: Christoph Hellwig <hch@lst.de>
To: Hannes Reinecke <hare@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Keith Busch <kbusch@kernel.org>,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH 1/8] nvme-keyring: restrict match length for version '1' identifiers
Date: Fri, 19 Jul 2024 07:34:33 +0200 [thread overview]
Message-ID: <20240719053433.GA21535@lst.de> (raw)
In-Reply-To: <20240718144858.19074-2-hare@kernel.org>
On Thu, Jul 18, 2024 at 04:48:51PM +0200, Hannes Reinecke wrote:
> TP8018 changed the TLS PSK identifiers to append a PSK hash value,
> so to lookup identifiers we should just consider the length of
> the match value, not the length of the identifiers to compare
> against.
> And we should modify the PSK lookup algorithm to prefer v1 identifiers
> as they can be uniquely identified.
Can you reword this a bit to remove the weird "we should" and state it
in terms of requirements / recommendations from the standard. Bonus
points for adding actual references to the specifications.
> @@ -109,19 +107,38 @@ static struct key *nvme_tls_psk_lookup(struct key *keyring,
> *
> * 'Retained' PSKs (ie 'generated == false')
> * should be preferred to 'generated' PSKs,
> + * PSKs with hash (psk_ver 1) should be
> + * preferred to PSKs without (psk_ver 0),
> * and SHA-384 should be preferred to SHA-256.
Please reflow this to use up 80 characters and make the paragraph easily
readable.
next prev parent reply other threads:[~2024-07-19 5:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 14:48 [PATCHv6 0/8] nvme: fixes for secure concatenation Hannes Reinecke
2024-07-18 14:48 ` [PATCH 1/8] nvme-keyring: restrict match length for version '1' identifiers Hannes Reinecke
2024-07-19 5:34 ` Christoph Hellwig [this message]
2024-07-19 6:16 ` Hannes Reinecke
2024-07-18 14:48 ` [PATCH 2/8] nvme-tcp: sanitize TLS key handling Hannes Reinecke
2024-07-19 5:35 ` Christoph Hellwig
2024-07-18 14:48 ` [PATCH 3/8] nvme-tcp: check for invalidated or revoked key Hannes Reinecke
2024-07-19 5:37 ` Christoph Hellwig
2024-07-18 14:48 ` [PATCH 4/8] nvme: add a newline to the 'tls_key' sysfs attribute Hannes Reinecke
2024-07-19 5:37 ` Christoph Hellwig
2024-07-18 14:48 ` [PATCH 5/8] nvme-sysfs: add 'tls_configured_key' " Hannes Reinecke
2024-07-19 5:44 ` Christoph Hellwig
2024-07-19 6:29 ` Hannes Reinecke
2024-07-18 14:48 ` [PATCH 6/8] nvme-sysfs: add 'tls_keyring' attribute Hannes Reinecke
2024-07-18 14:48 ` [PATCH 7/8] nvmet-auth: allow to clear DH-HMAC-CHAP keys Hannes Reinecke
2024-07-18 14:48 ` [PATCH 8/8] nvme-target: do not check authentication status for admin commands twice Hannes Reinecke
2024-07-19 5:45 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240719053433.GA21535@lst.de \
--to=hch@lst.de \
--cc=hare@kernel.org \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.