Open jbaublitz opened 6 months ago
A few initial thoughts in terms of design:
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.)
Another argument is of course: "This is how LUKS works, why would Stratis be different."
@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?
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?" :-)
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.
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.
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.