Subject: [Openpgp-dt] How much do we crypto-refresh RSA in OpenPGP?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 09 Mar 2022 23:49:48 -0500

Hey OpenPGP DT folks--

We're tasked with doing a cryptographic refresh, and draft -05 does a
lot of that.  One outstanding thing is OpenPGP's use of RSA, though:

    https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/22

brian m. carlson suggests in the above issue using RSA-PSS for
signatures and RSA-OAEP for encryption.

Do we want to tackle this in the next draft?

The main objection i can see to making these changes is that it we're on
path to deprecate RSA anyway (it is no longer MTI), and it could end up
being code churn.

I see two high-level approaches to doing this kind of change:

 a) Coupling the choice of RSA mechanism to the version of the key (RSA
    v5 uses the new schemes)
 
 b) Introducing new pubkey algorithm identifier(s)

An advantage of (a) is that it provides a clear sunset mechanism for the
older RSA schemes -- once v4 keys are deprecated, OpenPGP will only use
PSS and OAEP for RSA.

I suppose one advantage of (b) is that v4 implementations could use the
newer schemes without implementing v5.

Another possible approach would be a combination:

 c) new pubkey IDs, but they can only be used with v5 keys

I'm not sure what the advantage of this would be, but maybe someone
wants to advocate for it?

And of course there's the status quo:

 d) do not adopt RSA-PSS or RSA-OEAP in OpenPGP

Anyone want to propose another options?

Anyone want to advocate for one of these approaches?  Or object to one
of them?  Anyone want to suggest a concrete patch?

If this seems like too much to tackle, another angle to approach this
might be to split out the questions about signing and verifying with RSA
keys (RSA-PSS) from the questions about encrypting and decrypting with
RSA keys (RSA-OAEP).  If it's easier to propose an update that handles
just one of these aspects, feel free to suggest it.  We can always try
to tackle the other one later.

<taking my chair hat off>

I personally prefer choice (a).

My reasoning is:

Users and implementations already have a challenge when creating a new
public key: what version to generate?  There's no way to tell whether
other implementations can make use of the new format. If the user or
implementation generating an RSA key now *also* has to choose which
flavor of RSA key, that seems like yet another difficult thing to ponder.
I'd like to minimize the amount of unanswerable questions we put on
OpenPGP implementers and users.

I'd like to know what other folks think.

    --dkg

---

From: Justus Winter <[email-masked]>
Date: Mon, 28 Mar 2022 15:14:14 +0200

> of them?  Anyone want to suggest a concrete patch?

Based on the amount of excitement this has generated, I now think we
should go with d).

Justus

---

From: Daniel Huigens <[email-masked]>
Date: Mon, 28 Mar 2022 13:18:42 +0000

(I had the following draft sitting in my mailbox that I never sent out:)

>From a spec perspective, I dislike binding algorithm behavior to
key versions (i.e. option a).

> older RSA schemes -- once v4 keys are deprecated, OpenPGP will only use

I think that it's easier to deprecate the RSA algorithms than it is to
deprecate v4 keys. The former already have a widely supported
alternative (ECC), the latter don't yet.

In general, because of that, I don't see a strong reason to add RSA-PSS
and RSA-OAEP. Yes, of course they're much better than the current
flavors of RSA, but to justify adding them, they would also need to
have some advantage over ECC. Do they?

(If not, I also support option d.)

Best,
Daniel

---

From: Daniel Huigens <[email-masked]>
Date: Mon, 28 Mar 2022 13:22:37 +0000

(I sent that without the first quotation mark, I think, not sure how
that got in there :))

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 28 Mar 2022 17:46:47 -0400

> (I sent that without the first quotation mark, I think, not sure how

I think you're talking about the ">" before the line starting with
"From" as the message appears in
https://mailarchive.ietf.org/arch/msg/openpgp-dt/1PNWL8ZRsW9H_CU1i2lK87AUAcs/
If so, that's due to "From-munging", a relic of the so-called "mboxo"
variant of the mbox format:

   https://en.wikipedia.org/wiki/Mbox#Mbox_family
   https://datatracker.ietf.org/doc/html/rfc3676#section-4.4

fwiw, i received a different copy of the message, because i was in Cc.
My direct copy was encrypted, unlike the copy that went to the mailing
list.  I'm assuming that it's a deliberate protonmail feature that i get
a signed+encrypted copy even though the other copy that went to the list
went out unsigned in the clear.  The copy i got was *not* From-munged
(of course the ciphertext of the message routed to me would not have
been From-mungeable).

Below, I'm trying to trigger from-munging in this message, to see
whether something in the IETF mailing list archive modifies the content
of a multipart/signed message:

From munging is harmful in 2022!

I hope this message makes it into the archive such that the signature
can be verified.  If it cannot be verified, then something in the path
to the IETF mailarchive is breaking §2.1 of RFC 1847:

   Intermediate message transfer agents must not alter the content of a
   multipart/signed in any way, including, but not limited to, changing
   the content transfer encoding of the body part or any of its
   encapsulated body parts.

Here's hoping it works!

    --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 28 Mar 2022 19:18:02 -0400

Here is another test:

>From a simpler mail user agent, but still signed.

     --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 28 Mar 2022 20:03:43 -0400

>>From a simpler mail user agent, but still signed.

OK, my previous message didn't break because my mail user agent
pre-munged it by encoding the text/plain MIME part as quoted-printable,
so that it came out as:

From=20munging is harmful in 2022!

But the message quoted here ("From a simpler…") does no such encoding,
and the message when it came through the mailing list (and where it
appears in the archive at
https://mailarchive.ietf.org/arch/msg/openpgp-dt/6mqbfSI5OVmVtF9R6i2zSSjYx4M/
) has the "From" in the message body munged.

I've reported this to the maintainers of the IETF mailarchive project:

     https://github.com/ietf-tools/mailarch/issues/3487

In the meantime, if you control your own MUA, you might consider
scanning outbound messages for a line that begins with "From " (that's
From followed by a space) and if they are present, apply a
quoted-printable encoding to that part and ensure that the space is
encoded as =20.

ugh, legacy workarounds.  sorry for the on-list noise, i recommend
sending all further followup on this issue to that github ticket.

     --dkg

---

From: Daniel Huigens <[email-masked]>
Date: Tue, 29 Mar 2022 09:14:49 +0000

Ah, interesting. I was vaguely aware of that but am amazed that I
managed to trigger it accidentally. Thanks for the links! :)