Re: [openpgp] [RFC4880bis PATCH] Drop "Compatibility Profiles" section.

[Paul Wouters <[e-mail]>]

On Fri, 26 Mar 2021, Ángel wrote:

>> I'm attaching the
>> proposed patch below so that people following the list can see it.
>
> Hi Daniel
>
> Yep. I wanted it to appear on top of merge_requests/41 but did not find
> how to do that. Happy to learn how to do that.
>
> Now that Paul has merged your branch, I have rebased it and opened a
> direct MR against the main repository:
> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/44

I had a look at it. While some text indeed is weird because of the move
from an ECC only document into the generic bis document, I think some
of the text you suggest removing might still make sense, such as the
recommendations of hash algorithms for these curves. And that the place
within the document might be right too?

> I considered it. That (and folllowing) paragraphs look mostly fine. The
> problem there is the part about "use the strongest algorithms specified
> in this document". On 6637 that refers to the algorithm strength it is
> defining (i.e. the previous paragraphs that get removed). I considered
> whether it could be amended. That could end up as "use the strongest
> algorithms as defined by local policy", "as defined by the implementer"
> or some similarly vague description which wasn't really satisfactory.
> Also note that "specified in this document" changes meanings when put
> in 4880-refresh than in 6637 which was just about ECC.

I agree that needs fixing. The question is how/when to do this. If we
cut the entire section as you propose, we need to a file a tracking bug
to re-evaluate what to bring back, revised or verbatim later on in the
process when we are pulled up all the existing non-controversial work.

> I think we're better clearing it and seeing what is importable. I may
> have missed some sentence, but I doubt you could keep most of it as
> such.*

I think that could work, but let's get the opinion of a few others ?

> (*) A phrase that got removed but should be recovered is «MDC MUST be
> used when a symmetric encryption key is protected by ECDH.». I pondered
> where to move it, but I concluded that should better go at its own
> changeset stating that new algorithms cannot be used without MDC i.e.
> they cannot be used with the "Symmetrically Encrypted Data Packet"
> (still somewhat redundant, as that one MUST NOT be created).

If others agree, we need a tracking item for this too?

> Additionally, the phrase "A compliant application MUST only use
> iterated and salted S2K"... is also mostly fine, 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?

> If you find other phrases being removed that you think should have been
> kept, I would be happy discuss them in more detail. But for now, and
> after carefully reviewing the change itself, I stand by the proposal I
> did.

Note I only looked at the diff, I did not go looking for other phrases.

Paul