On 2021-03-25 at 01:31 +0100, Ángel wrote:
On 2021-02-28 at 23:09 +0100, Ángel wrote:
I would suggest a didactic approach, something like
Simple S2K and Salted S2K specifiers are not particularly secure
when used with a low-entropy secret, such as those typically
provided
by users, and implementations SHOULD avoid using these methods on
encryption of both keys and messages.
Best regards
As there were no further opinions, I have proposed this on
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/42
On
https://mailarchive.ietf.org/arch/msg/openpgp/Ym5J-1SQd-AwFLT0ypqyDCqUU18
Paul comments on this point:
but I had already covered a proposal for that one in the previous
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/42
I would need to hear from more people about this change to see if there
is consensus for this.
speaking with no roles others than an individual:
You suggest:
- Implementations SHOULD use salted or iterated-and-salted S2K
specifiers,
- as simple S2K specifiers are more vulnerable to dictionary attacks.
+ Simple S2K and Salted S2K specifiers are not particularly secure
when used
+ with a low-entropy secret, such as those typically provided by
users, and
+ implementations SHOULD avoid using these methods on encryption of
both keys and messages.
[...]
- A compliant application MUST only use iterated and salted S2K to
protect private keys,
- as defined in {{iterated-and-salted-s2k}}, "Iterated and Salted
S2K".
I think merging these two as you done is fine. I would try to use "SHOULD NOT
use"
instead of "SHOULD avoid".
I don't think the phrasing of "not particularly secure". Can it not just say
"weak" or
"vulnerable to low cost attacks" ?
Also, if it is this bad, why is this a SHOULD and not a MUST ? That is,
when would be a valid reason for an implementation to ignore the SHOULD?
Recapping:
- Text from RFC 6637 said «MUST only use iterated and salted S2K»
- Neal pointed that precludes private S2K algorithms, and suggested
«MUST NOT use Simple S2K and MUST NOT use Salted S2K»
- dkg noted they could be allowed if the string is known to be of high
entropy.
- Peter translated that to «Where it's likely that a low-entropy secret
is being employed, a compliant application SHOULD use [...]»
- I finally rephrased it adding the explanation on why we don't like
those two methods.
So:
why is this a SHOULD and not a MUST ?
Because of the scenario brought up by dkg that a system which
knows that the string is high-entropy ("good key equivalent") should
not be prohibited from using those.
If we agree this is a legitimate concern, this should be kept as a
SHOULD. No point into getting into the specific scenarios it may be
allowed or not.
On the other hand, the working group may consider that's not a
compelling reason to SHOULD it, and to use an iterated and salted even
if you have a perfect-grade passphrase.
I see value in both propositions.
I'm fine with changing SHOULD avoid into SHOULD NOT. That asks for
changing the both into either, as well. Not a problem.
I don't think the phrasing of "not particularly secure". Can it not
just say "weak" or "vulnerable to low cost attacks" ?
What about simply "are not secure" ?
Best regards
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp