From: Apoorv Kothari <apoorvko@amazon.com>
To: <sd@queasysnail.net>
Cc: <apoorvko@amazon.com>, <fkrenzel@redhat.com>, <kuniyu@amazon.com>,
<netdev@vger.kernel.org>
Subject: Re: [PATCH net-next 3/5] tls: implement rekey for TLS1.3
Date: Wed, 18 Jan 2023 17:25:46 -0800 [thread overview]
Message-ID: <20230119012546.36951-1-apoorvko@amazon.com> (raw)
In-Reply-To: <Y8fMLtYmlIw2wfMM@hog>
> 2023-01-17, 15:16:33 -0800, Kuniyuki Iwashima wrote:
> > Hi,
> >
> > Thanks for posting this series!
> > We were working on the same feature.
> > CC Apoorv from s2n team.
>
> Ah, cool. Does the behavior in those patches match what your
> implementation?
Thanks for submitting this, it looks great! We are working on testing this now.
>
> [...]
> > > diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
> > > index fb1da1780f50..9be82aecd13e 100644
> > > --- a/net/tls/tls_main.c
> > > +++ b/net/tls/tls_main.c
> > > @@ -669,9 +669,12 @@ static int tls_getsockopt(struct sock *sk, int level, int optname,
> > > static int do_tls_setsockopt_conf(struct sock *sk, sockptr_t optval,
> > > unsigned int optlen, int tx)
> > > {
> > > + union tls_crypto_context tmp = {};
> > > + struct tls_crypto_info *old_crypto_info = NULL;
> > > struct tls_crypto_info *crypto_info;
> > > struct tls_crypto_info *alt_crypto_info;
> > > struct tls_context *ctx = tls_get_ctx(sk);
> > > + bool update = false;
> > > size_t optsize;
> > > int rc = 0;
> > > int conf;
> > > @@ -687,9 +690,17 @@ static int do_tls_setsockopt_conf(struct sock *sk, sockptr_t optval,
> > > alt_crypto_info = &ctx->crypto_send.info;
> > > }
> > >
> > > - /* Currently we don't support set crypto info more than one time */
> > > - if (TLS_CRYPTO_INFO_READY(crypto_info))
> > > - return -EBUSY;
> > > + if (TLS_CRYPTO_INFO_READY(crypto_info)) {
> > > + /* Currently we only support setting crypto info more
> > > + * than one time for TLS 1.3
> > > + */
> > > + if (crypto_info->version != TLS_1_3_VERSION)
> > > + return -EBUSY;
> > > +
> >
> > Should we check this ?
> >
> > if (!tx && !key_update_pending)
> > return -EBUSY;
> >
> > Otherwise we can set a new RX key even if the other end has not sent
> > KeyUpdateRequest.
>
> Maybe. My thinking was "let userspace shoot itself in the foot if it
> wants".
I feel avoiding foot-guns is probably the correct thing to do. The RFC also has
a requirement that re-key(process messages with new key) should only happen after
a KeyUpdate is received so it would be nice if the kTLS implemention can help
enforce this.
Based on the RFC https://www.rfc-editor.org/rfc/rfc8446#section-4.6.3:
Additionally, both sides MUST enforce that a KeyUpdate
with the old key is received before accepting any messages encrypted
with the new key. Failure to do so may allow message truncation
attacks.
>
> > > + update = true;
> > > + old_crypto_info = crypto_info;
> > > + crypto_info = &tmp.info;
> > > + }
> > >
> > > rc = copy_from_sockptr(crypto_info, optval, sizeof(*crypto_info));
> > > if (rc) {
> > > @@ -704,6 +715,15 @@ static int do_tls_setsockopt_conf(struct sock *sk, sockptr_t optval,
> > > goto err_crypto_info;
> > > }
> > >
> > > + if (update) {
> > > + /* Ensure that TLS version and ciphers are not modified */
> > > + if (crypto_info->version != old_crypto_info->version ||
> > > + crypto_info->cipher_type != old_crypto_info->cipher_type) {
> > > + rc = -EINVAL;
> > > + goto err_crypto_info;
> > > + }
> > > + }
> > > +
> > > /* Ensure that TLS version and ciphers are same in both directions */
> > > if (TLS_CRYPTO_INFO_READY(alt_crypto_info)) {
> >
> > We can change this to else-if.
>
> Ok.
>
> > > if (alt_crypto_info->version != crypto_info->version ||
> [...]
> > > @@ -2517,9 +2525,28 @@ int tls_set_sw_offload(struct sock *sk, int tx)
> > > u16 nonce_size, tag_size, iv_size, rec_seq_size, salt_size;
> > > struct crypto_tfm *tfm;
> > > char *iv, *rec_seq, *key, *salt, *cipher_name;
> > > - size_t keysize;
> > > + size_t keysize, crypto_info_size;
> > > int rc = 0;
> > >
> > > + if (new_crypto_info) {
> > > + /* non-NULL new_crypto_info means rekey */
> > > + src_crypto_info = new_crypto_info;
> > > + if (tx) {
> > > + sw_ctx_tx = ctx->priv_ctx_tx;
> > > + crypto_info = &ctx->crypto_send.info;
> > > + cctx = &ctx->tx;
> > > + aead = &sw_ctx_tx->aead_send;
> > > + sw_ctx_tx = NULL;
> >
> > sw_ctx_tx is already initialised.
>
> No, it was NULL at the beginning of the function, but then I used it
> to set aead on the previous line, so I need to clear it again. I could
> use a temp variable instead if you think it's better.
>
> > > + } else {
> > > + sw_ctx_rx = ctx->priv_ctx_rx;
> > > + crypto_info = &ctx->crypto_recv.info;
> > > + cctx = &ctx->rx;
> > > + aead = &sw_ctx_rx->aead_recv;
> > > + sw_ctx_rx = NULL;
> >
> > Same here.
> >
> >
> > > + }
> > > + goto skip_init;
> > > + }
> > > +
> > > if (tx) {
> > > if (!ctx->priv_ctx_tx) {
> > > sw_ctx_tx = kzalloc(sizeof(*sw_ctx_tx), GFP_KERNEL);
>
> Thanks for the comments.
>
> --
> Sabrina
--
Apoorv
next prev parent reply other threads:[~2023-01-19 1:31 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 13:45 [PATCH net-next 0/5] tls: implement key updates for TLS1.3 Sabrina Dubroca
2023-01-17 13:45 ` [PATCH net-next 1/5] tls: remove tls_context argument from tls_set_sw_offload Sabrina Dubroca
2023-01-18 23:12 ` Vadim Fedorenko
2023-01-17 13:45 ` [PATCH net-next 2/5] tls: block decryption when a rekey is pending Sabrina Dubroca
2023-01-19 2:10 ` [PATCH net-next 0/5] tls: implement key updates for TLS1.3 Apoorv Kothari
2023-01-17 13:45 ` [PATCH net-next 3/5] tls: implement rekey " Sabrina Dubroca
2023-01-17 23:16 ` Kuniyuki Iwashima
2023-01-18 10:38 ` Sabrina Dubroca
2023-01-19 1:25 ` Apoorv Kothari [this message]
2023-01-19 15:16 ` Sabrina Dubroca
2023-01-18 23:10 ` Vadim Fedorenko
2023-01-19 15:14 ` Sabrina Dubroca
2023-01-17 13:45 ` [PATCH net-next 4/5] selftests: tls: add key_generation argument to tls_crypto_info_init Sabrina Dubroca
2023-01-17 13:45 ` [PATCH net-next 5/5] selftests: tls: add rekey tests Sabrina Dubroca
2023-01-20 6:51 ` Apoorv Kothari
2023-01-18 2:03 ` [PATCH net-next 0/5] tls: implement key updates for TLS1.3 Jakub Kicinski
2023-01-18 10:06 ` Sabrina Dubroca
2023-01-19 2:55 ` Jakub Kicinski
2023-01-19 9:27 ` Gal Pressman
2023-01-23 10:13 ` Boris Pismenny
2023-01-24 15:56 ` Sabrina Dubroca
2023-01-25 18:47 ` Apoorv Kothari
2023-01-25 18:57 ` Jakub Kicinski
2023-01-25 21:17 ` Simo Sorce
2023-01-25 22:43 ` Jakub Kicinski
2023-01-25 23:05 ` Simo Sorce
2023-01-25 23:08 ` Jakub Kicinski
2023-01-25 23:52 ` Simo Sorce
2023-01-19 15:40 ` Sabrina Dubroca
2023-01-19 17:00 ` Jakub Kicinski
2023-01-19 20:51 ` Apoorv Kothari
2023-01-20 1:37 ` Vadim Fedorenko
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=20230119012546.36951-1-apoorvko@amazon.com \
--to=apoorvko@amazon.com \
--cc=fkrenzel@redhat.com \
--cc=kuniyu@amazon.com \
--cc=netdev@vger.kernel.org \
--cc=sd@queasysnail.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).