All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Xin Long <lucien.xin@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	linux-crypto@vger.kernel.org
Subject: Re: [PATCH net-next v2 3/3] sctp: Convert cookie authentication to use HMAC-SHA256
Date: Fri, 15 Aug 2025 14:50:09 -0700	[thread overview]
Message-ID: <20250815215009.GA2041@quark> (raw)
In-Reply-To: <CADvbK_csEoZhA9vnGnYbfV90omFqZ6dX+V3eVmWP7qCOqWDAKw@mail.gmail.com>

On Fri, Aug 15, 2025 at 05:19:27PM -0400, Xin Long wrote:
> On Fri, Aug 15, 2025 at 3:09 PM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Tue, 12 Aug 2025 21:01:21 -0700 Eric Biggers wrote:
> > > +     if (net->sctp.cookie_auth_enable)
> > > +             tbl.data = (char *)"sha256";
> > > +     else
> > > +             tbl.data = (char *)"none";
> > > +     tbl.maxlen = strlen(tbl.data);
> > > +     return proc_dostring(&tbl, 0, buffer, lenp, ppos);
> >
> > I wonder if someone out there expects to read back what they wrote,
> > but let us find out.
> I feel it's a bit weird to have:
> 
> # sysctl net.sctp.cookie_hmac_alg="md5"
> net.sctp.cookie_hmac_alg = md5
> # sysctl net.sctp.cookie_hmac_alg
> net.sctp.cookie_hmac_alg = sha256
> 
> This patch deprecates md5 and sha1 use there.
> So generally, for situations like this, should we also issue a
> warning, or just fail it?
> 
> Paolo, what do you think?
> 
> >
> > It'd be great to get an ack / review from SCTP maintainers, otherwise
> > we'll apply by Monday..
> Other than that, LGTM.
> Sorry for the late reply, I was running some SCTP-auth related tests
> against the patchset.

Ideally we'd just fail the write and remove the last mentions of md5 and
sha1 from the code.  But I'm concerned there could be a case where
userspace is enabling cookie authentication by setting
cookie_hmac_alg=md5 or cookie_hmac_alg=sha1, and by just failing the
write the system would end up with cookie authentication not enabled.

It would have been nice if this sysctl had just been a boolean toggle.

A deprecation warning might be a good idea.  How about the following on
top of this patch:

diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
index 19acc57c3ed97..72af4a843ae52 100644
--- a/net/sctp/sysctl.c
+++ b/net/sctp/sysctl.c
@@ -399,20 +399,28 @@ static int proc_sctp_do_hmac_alg(const struct ctl_table *ctl, int write,
 		tbl.data = tmp;
 		tbl.maxlen = sizeof(tmp) - 1;
 		ret = proc_dostring(&tbl, 1, buffer, lenp, ppos);
 		if (ret)
 			return ret;
-		if (!strcmp(tmp, "sha256") ||
-		    /* for backwards compatibility */
-		    !strcmp(tmp, "md5") || !strcmp(tmp, "sha1")) {
+		if (!strcmp(tmp, "sha256")) {
 			net->sctp.cookie_auth_enable = 1;
 			return 0;
 		}
 		if (!strcmp(tmp, "none")) {
 			net->sctp.cookie_auth_enable = 0;
 			return 0;
 		}
+		/*
+		 * Accept md5 and sha1 for backwards compatibility, but treat
+		 * them simply as requests to enable cookie authentication.
+		 */
+		if (!strcmp(tmp, "md5") || !strcmp(tmp, "sha1")) {
+			pr_warn_once("net.sctp.cookie_hmac_alg=%s is deprecated. Use net.sctp.cookie_hmac_alg=sha256\n",
+				     tmp);
+			net->sctp.cookie_auth_enable = 1;
+			return 0;
+		}
 		return -EINVAL;
 	}
 	if (net->sctp.cookie_auth_enable)
 		tbl.data = (char *)"sha256";
 	else

  reply	other threads:[~2025-08-15 21:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-13  4:01 [PATCH net-next v2 0/3] sctp: Convert to use crypto lib, and upgrade cookie auth Eric Biggers
2025-08-13  4:01 ` [PATCH net-next v2 1/3] selftests: net: Explicitly enable CONFIG_CRYPTO_SHA1 for IPsec Eric Biggers
2025-08-13  4:01 ` [PATCH net-next v2 2/3] sctp: Use HMAC-SHA1 and HMAC-SHA256 library for chunk authentication Eric Biggers
2025-08-13  4:01 ` [PATCH net-next v2 3/3] sctp: Convert cookie authentication to use HMAC-SHA256 Eric Biggers
2025-08-15 19:09   ` Jakub Kicinski
2025-08-15 21:19     ` Xin Long
2025-08-15 21:50       ` Eric Biggers [this message]
2025-08-16  1:06         ` Jakub Kicinski
2025-08-16 17:15           ` Xin Long
2025-08-18 15:43             ` Jakub Kicinski
2025-08-18 17:31               ` Eric Biggers
2025-08-18 17:41                 ` Xin Long
2025-08-18 17:42 ` [PATCH net-next v2 0/3] sctp: Convert to use crypto lib, and upgrade cookie auth Xin Long

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=20250815215009.GA2041@quark \
    --to=ebiggers@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /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.