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

Ángel <angel@16bits.net> Sat, 27 March 2021 03:16 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 43A0D3A1C3B for <openpgp@ietfa.amsl.com>; Fri, 26 Mar 2021 20:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 Tft_HCgn86-c for <openpgp@ietfa.amsl.com>; Fri, 26 Mar 2021 20:15:58 -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 68C903A1C00 for <openpgp@ietf.org>; Fri, 26 Mar 2021 20:15:56 -0700 (PDT)
Message-ID: <b4c6cb0b929dff027b28df546e4d90560dbba94f.camel@16bits.net>
From: =?ISO-8859-1?Q?=C1ngel?= <angel@16bits.net>
To: openpgp@ietf.org
Date: Sat, 27 Mar 2021 04:15:52 +0100
In-Reply-To: <ba29e6e3-7fe8-4ed6-819c-b0d0a22ec24@nohats.ca>
References: <87wnu86mep.fsf@fifthhorseman.net> <20210324021213.333485-1-dkg@fifthhorseman.net> <87pmzp2taf.fsf@fifthhorseman.net> <26945b02701cdbcf7af0ebd3adaa325b91021be7.camel@16bits.net> <87blb72yto.fsf@fifthhorseman.net> <029c60b6a313d33cf5cc7e15791be8c0c582370c.camel@16bits.net> <ba29e6e3-7fe8-4ed6-819c-b0d0a22ec24@nohats.ca>
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/vhbKnA8a0bSOPm8URY40V70e_y8>
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: Sat, 27 Mar 2021 03:16:02 -0000

On 2021-03-25 at 23:27 -0400, Paul Wouters wrote:
> 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. 

Good point, that table may be useful without the requirement levels.

> And that the place within the document might be right too?

That's an editorial matter, but I don't think so. I find the security
section to contain many things without a clear script, just a mixture
of things related to security. The problem is that most of the rfc has
some relation to security :-)
There are rfcs with only a few security points to note. Having a
section listing all of them is good. But I don't think that's suitable 
for OpenPGP.

I would prefer to see as little as possible on the Security
Considerations, with the points within the most relevant section to the
topic. See for example how I positioned the line about you MUST use
Iterated and salted s2k at the part discussing rather than in that
generic section. IMHO that makes more sense, instead of having a S2K
requisite in a complete separate part of the document.

Nevertheless, the Security Considerations need an overhaul. There are
multiple types of items: general advice, attack descriptions, key size
tables...
And it must grow, some of that is outdated, while other missing.

That ECC table I would probably place it at its own section, probably
as a 13.5.

Other points should perhaps be 15.x subsections.



> > (...)
> 
> 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 agree with opening a task to reevaluate that later, if merged.
This was not intended as a permanent removal.


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

Yes, probably. Unless we get a quick consensus on this topic.


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

This part was proposed in February on a different thread. I am moving
your comment there and replying in that one:

https://mailarchive.ietf.org/arch/msg/openpgp/ml5gzuQtSY6ANBejs8Xk66x_abQ


Regards