From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D629B6FA1 for ; Mon, 3 Apr 2023 16:13:41 +0000 (UTC) Received: by mail-wm1-f44.google.com with SMTP id v6-20020a05600c470600b003f034269c96so8220650wmo.4 for ; Mon, 03 Apr 2023 09:13:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680538420; x=1683130420; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FeBep77DrjGUpmokRYQ7dhCDeDDySE9+TQjeaBuBkxw=; b=ltGeH6K0oE2zW9Jk1aCy3eNKfHk6/19jzbmOkw/e0eRPuPE9XrL+y1urKD+oT6edzf yMNq5/69hykitgolsvk4nQCjxI1byUfxzCejrlkHh4p5Up/CUkEJkEDvhr5qDTyB8C8S mCsxgCR9btoSn1cQCN/BaAVVqb1cUVEApOaiuJXlfV5RaqRpFkbwhsrSDis/Dhb5aZyU 2yzuX0fl2Cm2/KqX6PE9AOHKZO20FnP2fZxbBE0jiW10jsCLqItilKghGN0y1uAVuzTz FuhnQQZZQBMMKsyn1vzSXwrGN6aO08ev2AlQElUhjVTo0DzVAdEnujtt26FOIJR8cOrj dC1g== X-Gm-Message-State: AAQBX9dPqAaxSqVFe85VXZslMBSnpCK1tKb5EZb5cxIMJHSyCWUa8Ocp cihM7/fG7Dt4M6/2UalyzLA= X-Google-Smtp-Source: AKy350bQ6o8QlReTv05o8RCHu/tuH+y9+1PJGi+S4jdqiRhnA4MrEOz08syRp5I8Z5QCs7FLin6BFQ== X-Received: by 2002:a05:600c:5399:b0:3ee:da0:cb85 with SMTP id hg25-20020a05600c539900b003ee0da0cb85mr61777wmb.1.1680538420020; Mon, 03 Apr 2023 09:13:40 -0700 (PDT) Received: from [192.168.64.192] (bzq-219-42-90.isdn.bezeqint.net. [62.219.42.90]) by smtp.gmail.com with ESMTPSA id bd6-20020a05600c1f0600b003ef36ef3833sm19541576wmb.8.2023.04.03.09.13.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Apr 2023 09:13:39 -0700 (PDT) Message-ID: <7e7c3787-1772-c719-9765-7d271100dffe@grimberg.me> Date: Mon, 3 Apr 2023 19:13:38 +0300 Precedence: bulk X-Mailing-List: kernel-tls-handshake@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 12/18] nvme-fabrics: parse options 'keyring' and 'tls_key' Content-Language: en-US To: Hannes Reinecke , Christoph Hellwig Cc: Keith Busch , linux-nvme@lists.infradead.org, Chuck Lever , kernel-tls-handshake@lists.linux.dev References: <20230329135938.46905-1-hare@suse.de> <20230329135938.46905-13-hare@suse.de> <677f3f9a-872d-27fe-9a21-b41bbe1c44ff@grimberg.me> <32a81d27-2c16-b71b-e9da-d704acda93f6@suse.de> From: Sagi Grimberg In-Reply-To: <32a81d27-2c16-b71b-e9da-d704acda93f6@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/3/23 17:11, Hannes Reinecke wrote: > On 4/3/23 15:07, Sagi Grimberg wrote: >> >>>>>>> Parse the fabrics options 'keyring' and 'tls_key' and store the >>>>>>> referenced keys in the options structure. >>>>>> >>>>>> Can you explain the reasoning to why a user need to pass a keyring >>>>>> given that we already set up one? >>>>>> >>>>> Choice. >>>>> With a single keyring we can only have a single identity. >>>>> But there might be configurations where we want to have different PSKs >>>>> for the same identity (eg for key rotation). >>>> >>>> How do you expect that rotation would work with this? >>>> >>> The user creates a new keyring, adds the necessary keys to it, and then >>> either >>> - updates the keyring for nvmet (via configfs) >>> or >>> - reconnects using the new keyring >> >> And the user cannot update the nvme keyring? >> > Sure, he can. All I'm saying is that he might choose to create a > different one (Different tenants, setups, what do I know). > >>>> How does nvmet handle a non-nvme keyring? >>>> >>> There is a configfs attribute 'param_keyring', allowing you to use a >>> different keyring (the nvme one is just the default). >> >> OK. >> >>>>> With this option we can prepare a new keyring, and use that instead >>>>> of the old one. >>>> >>>> On an existing controller? >>>> >>> Sure; when we are updating the keyring and the key id the controller >>> will use that after the next reset. >>> Much like we do for DH-CHAP nowadays. >>> >>>>> (And it really doesn't add much complexity...) >>>> >>>> I know, it just adds one more argument, and I want to understand if it >>>> is really needed. >>> >>> I do agree that the keyring argument would not necessarily required >>> if we pass in the key id, but I'll be needing the keyring for secure >>> concatenation. And plan is to move DH-HMAC-CHAP over to keyrings, too. >> >> I'm not sure I understand why authentication move to keyrings requires >> that the user is able to bring its own keyring. >> >>> So I'd prefer to keep it. >> >> I'm not against it, but I failing to understand in what situation a user >> _must_ send a different keyring to the driver (and not use the nvme >> keyring). > > Oh, there is no 'must'. He _can_. And under certain circumstances > (in a multi-tenant environment, say) there are reasons to keep the keys > separate into several keyrings. > Bit like the '--key' parameter; the code will try to select the > 'default' key, but if the user wants to use a different one by all > means, do. > Same for the keyring; we do have the default keyring, but if the user > for whatever reason doesn't want to use it we're giving him the > possibility for that. I'm not overly keen to overload the argument space without proper real-life justification. But maybe it does make sense to allow users to store their secrets in separate keyrings... So I'm not really opposed to this one.