Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd)

From: "Neal H. Walfield" <[email-masked]>
Date: Mon, 01 Mar 2021 12:38:32 +0100

On Sat, 27 Feb 2021 05:41:04 +0100,
Daniel Kahn Gillmor wrote:
> Hi Neal--
> 
> Thanks for the nit-picks.  Two concerns:
> 
> On Fri 2021-02-26 12:50:17 +0100, Neal H. Walfield wrote:
> > -- 20 octets representing a recipient encryption subkey or a master key fingerprint, identifying the key material that is needed for the decryption.
> > -  For version 5 keys the 20 leftmost octets of the fingerprint are used.
> > +- [ ] 20 octets representing a recipient encryption subkey or a primary key fingerprint identifying the key material that is needed for decryption
> > +  (for version 5 keys the 20 leftmost octets of the fingerprint are used).

I don't know how that crept it.

> what does the [ ] you've inserted here mean?  It looks like a markdown
> todo-list "checkbox", maybe it was inserted by mistake?
> 
> > -    09 k0 k1 ... k31 c0 c1 05 05 05 05 05
> > +    09 k0 k1 ... k31 C0 C1 05 05 05 05 05
> >  
> > -The octets c0 and c1 above denote the checksum.
> > +The octets C0 and C1 above denote the checksum.
> 
> This seems like a mistake.  C0 and C1 could be specific hexadecimal
> octets (decimal 12), whereas "c0" and "c1" here are intended to be
> placeholders for the checksum.  This is a bit confusing, maybe it would
> be better to use s0 and s1 (s for "sum") so that it's clear that it
> isn't hex?

Good points!  I think using s0 and s1 is the best suggestion so far.

---

From: Ángel <[email-masked]>
Date: Thu, 25 Mar 2021 01:31:00 +0100

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

Note: I'm purposefully not adding anything at the Security section.
That section is currently a chaotic mixture. I think it would be best
to keep local issues at their corresponding section (maybe even
creating security subsections) and leave §15 for general one. By its
own nature, this spec will have many security-related points, and we
can't expect to repeat everything there.
In any case, imho we should organize it first, stripping it as much as
possible. It can be discussed later if some points really need to come
back.

Best regards

---

From: Ángel <[email-masked]>
Date: Sat, 27 Mar 2021 04:13:52 +0100

> 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
> 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