ietf-openpgp
[Top] [All Lists]

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

2021-03-25 22:27:41
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

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp