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

Ángel <angel@16bits.net> Fri, 26 March 2021 00:28 UTC

Return-Path: <angel@16bits.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C803A1189 for <openpgp@ietfa.amsl.com>; Thu, 25 Mar 2021 17:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOqscnZmf949 for <openpgp@ietfa.amsl.com>; Thu, 25 Mar 2021 17:28:50 -0700 (PDT)
Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711573A0B59 for <openpgp@ietf.org>; Thu, 25 Mar 2021 17:28:49 -0700 (PDT)
Message-ID: <029c60b6a313d33cf5cc7e15791be8c0c582370c.camel@16bits.net>
From: =?ISO-8859-1?Q?=C1ngel?= <angel@16bits.net>
To: openpgp@ietf.org
Date: Fri, 26 Mar 2021 01:28:47 +0100
In-Reply-To: <87blb72yto.fsf@fifthhorseman.net>
References: <87wnu86mep.fsf@fifthhorseman.net> <20210324021213.333485-1-dkg@fifthhorseman.net> <87pmzp2taf.fsf@fifthhorseman.net> <26945b02701cdbcf7af0ebd3adaa325b91021be7.camel@16bits.net> <87blb72yto.fsf@fifthhorseman.net>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/wFgkmhOwGFZlgZicWMjju8AK1Mg>
Subject: Re: [openpgp] [RFC4880bis PATCH] Drop "Compatibility Profiles" section.
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Mar 2021 00:28:55 -0000

On 2021-03-25 at 08:38 -0400, Daniel Kahn Gillmor wrote:
> On Thu 2021-03-25 02:20:16 +0100, Ángel wrote:
> > This issue also affected the security considerations section. I made a
> > follow-up at https://gitlab.com/dkg/rfc4880bis/-/merge_requests/1
> 
> Looks like you've done a merge request against my personal repo, rather
> than putting it in the openpgp-wg repo where everyone else will be able
> to see it -- i recommend making this MR against
> https://gitlab.com/openpgp-wg/rfc4880bis instead so that it gets public
> visibility, and the merge requests aren't scattered.  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 tried to keep what was salvable but ended up leaving just three lines
> > from rfc6637.
> 
> I'm not convinced that these specific security considerations are
> invalid given that the compatibility profiles section is gone.  For
> example, do we believe it to be untrue that:
> 
>     Compliant applications SHOULD implement, advertise through key
>     preferences, and use the strongest algorithms specified in this
>     document.
> 
> I think that looks correct, and I see no reason to cut it just because
> we've dropped the Compatibility Profiles section.


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 like some of the points it discusses, such as the order issue with
multiple recipients, but it still revolves around strength ("the
stronger encryption algorithm", "the weakest algorithm"...) which is no
longer defined.

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

We MAY want to provide a more complete table than was in 6637
(preferably as a new section, not embedded in Security), in which case
we could more easily reimport some bigger chunk.
That is worth its own discussion, though. I'm not convinced at this
point that 4880-refresh should explicitly state the relative strength
of each algorithm.


(*) 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).


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


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.

Best regards