Feature request for multiple encrypt unlock mechanisms

[jbaublitz]

A while back, @mvollmer requested the ability to add multiple keyslot bindings to encrypted pools. For example, instead of using the sss pin in Clevis, a user could simply add one keyslot that uses TPM and one keyslot that uses Tang. This seems like a feature that other users may be interested in.

Because we currently only support a static token slot in older versions of stratisd (token slot 1 for the keyring implementation and token slot 2 for Clevis), we will likely have to do some special handling in the new API for tokens slots 1 and 2. However, token slot 0 is no longer used in version 2 of the metadata and could be used for either. In version 1 of the metadata, this would still be reserved for the Stratis token. All token slots higher than 2 would be available for either implementation.

[jbaublitz]

A few initial thoughts in terms of design:

1. The unbind method could be collapsed into a single method (it would take a token slot as a parameter, remove the keyslot associated with the token, and then remove the token). Rebind and bind would still have to remain separate methods.
2. There could be an option to find the first free token slot if the user does not care which slot the token ends up in.
3. Special care will have to be taken to ensure that there is always 1 keyslot available to unlock the device.

[mvollmer]

A while back, @mvollmer requested the ability to add multiple keyslot bindings to encrypted pools.

"Request" is a strong word. :-) There are conceptual problems with using the "sss" pin, AFAICS: it can not be modified incrementally, and has to be constructed from scratch for every change. This requires all secrets that should go into its configuration. With LUKS slots, you only need one when adding a new slot, and none when removing a slot.

Also, I think there is no passphrase pin for tang. I can only find "null", "sss", "tang", "tpm2", and "tpm2plus". Thus clevis seems to be designed for non-interactive unlocking only.

(Please check all this if you think it might not be true. It has been a while and I might be wrong.)

[mvollmer]

Another argument is of course: "This is how LUKS works, why would Stratis be different."

[jbaublitz]

@mvollmer Apologies for the misinterpretation. :) I maybe thought you were more set on this as a feature than you were.

We're actually having some interesting conversations right now because of another point you raised around usability that I mostly agree with: having to remember the passphrase and the key description is not super usable.

Right now we're having some discussions about adding in the ability to specify multiple unlock mechanism, but this conflicts somewhat with our efforts to obscure the key description a bit.

How would you feel about support for multiple Clevis bindings, but no support for multiple passphrases as outlined here?

[mvollmer]

How would you feel about support for multiple Clevis bindings, but no support for multiple passphrases as outlined here?

That would be an improvement to the status quo, I'd say. I can't say how important the use cases are that require multiple passphrases. I am just always assuming that LUKS has figured out the use cases and am thinking, "Why is Stratis different from LUKS?" :-)

[jbaublitz]

How would you feel about support for multiple Clevis bindings, but no support for multiple passphrases as outlined here?

That would be an improvement to the status quo, I'd say. I can't say how important the use cases are that require multiple passphrases. I am just always assuming that LUKS has figured out the use cases and am thinking, "Why is Stratis different from LUKS?" :-)

One reason that we sometimes decide to diverge from the user experience of existing code that we use is if there is a compelling reason from a usability perspective. Stratis is not necessarily guaranteed to be as flexible as the underlying technologies. The reason for this is that Stratis aims to have an opinionated approach that does not necessarily work for everyone, but generally adopts best practices for the majority of users who are unfamiliar with storage. While allowing multiple passphrases attached to keyrings may be the best solution, I just want to highlight that we generally don't adopt the perspective of flexibility parity with all of our component technologies if we think that a prescriptive approach is better in certain cases. For example, cryptsetup also allows configuring the encryption cipher, but we do not. We use the default that will be best for most users.

[jbaublitz]

Just an update on this that we've had a lot of discussions about the pros and cons of this. We agree that this is a desirable feature and have added some preliminary work in #3637 to ease support for this in the future.