Re: [openpgp] Sec. Considerations MUST about S2K [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt]

[Ángel <[e-mail]>]

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