1665281 - Tb-native OpenPGP implementation does not use newer subkeys

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, defect)

Description

[Kosuke Kaizuka]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

I have a keypair with multiple subkeys shown below (RSA keypair is created in 2009, and ECC subkeys are added in 2020).

sec rsa4096/523DD5D34E8E48D9, created: 2009-10-26, usage: SC
ssb rsa4096/0C94EE97CC4A2E9C, created: 2009-10-26, usage: E
ssb ed25519/1CFC0F1D2839684B, created: 2020-07-01, usage: S
ssb cv25519/A1236D2F9431B88C, created: 2020-07-01, usage: E

I have upgraded Tb 68.12.0 to 78.2.2 via autoupdate, and migrated from Enigmail 2.1.8 to Tb-native OpenPGP implementation.
Keys and configurations are migrated successfully.

Testing signing/encryption with Tb-native OpenPGP.

Actual results:

1. A message via 4E8E48D9 is signed with 4E8E48D9 (primary key, RSA)
2. A message for 4E8E48D9 is encrypted with CC4A2E9C (older encryption key, RSA)

Expected results:

1. A message via 4E8E48D9 is signed with 2839684B (newer signing subkey, EdDSA)
2. A message for 4E8E48D9 is encrypted with 9431B88C (newer encryption key, ECDH)

Classic Tb (68 and below) + Enigmail + GnuPG uses the newer subkeys for signing/encryption.
Users of Tb + Enigmail + GnuPG expect the same behavior.

GnuPG itself and other GnuPG-based front-end applications also use the newer subkeys for signing/encryption.
(Maybe other OpenPGP implementations, too)

Comment 1

[Thomas D. (:thomas8)]

From support documentation:

https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq#w_what-types-of-openpgp-keys-are-supported

not or not yet supported...

• Keys that use a different password for a sub key

Comment 2

[Kosuke Kaizuka]

This is a kind of a decline of security level.

ex.
sec dsa1024/XXXXXXXXXXXXXXXX, created: 2009-10-26, usage: SC
ssb dsa1024/XXXXXXXXXXXXXXXX, created: 2009-10-26, usage: E
ssb ed25519/XXXXXXXXXXXXXXXX, created: 2020-07-01, usage: S
ssb cv25519/XXXXXXXXXXXXXXXX, created: 2020-07-01, usage: E

Once ago, user created DSA keypair, and recently added new EdDSA subkeys.
(Long-time OpenPGP users often have this kind of keys, old primary key + new subkeys.)

With classic Tb + Enigmail + GnuPG or most other environments, user can get 128-bit security level with EdDSA key.
However, Tb-native OpenPGP implementation forces user to get only 80-bit security level with old, weak DSA key.

(In reply to Thomas D. (:thomas8) from comment #1)

From support documentation:

https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq#w_what-types-of-openpgp-keys-are-supported

not or not yet supported...

• Keys that use a different password for a sub key

I cannot understand the situation "Keys that use a different password for a sub key".
Usually, OpenPGP keypair has only one passphrase even if it includes multiple subkeys, and all subkeys will be unlocked with this common passphrase.

Comment 3

[Kosuke Kaizuka]

Also posted on Thunderbird e2ee.
https://thunderbird.topicbox.com/groups/e2ee/T12a8f43ab17206ec/tb-native-openpgp-implementation-does-not-use-newer-subkeys

Comment 4

[Kai Engert [:KaiE:]]

We need to update code in Thunderbird's RNP.jsm to have a smarter lookup of the appropriate key. Currently, it's happy as soon as it finds key that's usable and is not expired/revoked. Your scenario has not yet been configured.

Is it always the correct decision to use the newer subkey?

Comment 5

[Nickolay Olshevsky]

I also filed an issue at https://github.com/rnpgp/rnp/issues/1313
However I still think that this should be controllable by enduser (with appropriate default, of course).

Comment 7

[Kai Engert [:KaiE:]]

Attachment: Bug 1665281 - Encrypt to most recently created OpenPGP encryption subkey. r=PatrickBrunschwig

Comment 8

[Kai Engert [:KaiE:]]

(In reply to Nickolay Olshevsky from comment #5)

However I still think that this should be controllable by enduser (with appropriate default, of course).

Let's consider that later, I've filed bug 1667232 to track that.

I suggest that for now we implement the simple compatibility fix (encrypt to single key, use newest).

Comment 9

[Kosuke Kaizuka]

Thank you for providing a patch.
Is this patch effective for both encryption and signing (in my case; sign with 0x2839684B, newer signing subkey, EdDSA)? or only for encryption?

Comment 10

[Kai Engert [:KaiE:]]

(In reply to Kosuke Kaizuka from comment #9)

Is this patch effective for both encryption and signing ... ?

yes, it should

I'd appreciate your feedback that it works as expected.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/8fc4a078751c
Encrypt to most recently created OpenPGP encryption subkey. r=PatrickBrunschwig DONTBUILD

Comment 12

[Kai Engert [:KaiE:]]

Comment on attachment 9177744 [details]
Bug 1665281 - Encrypt to most recently created OpenPGP encryption subkey. r=PatrickBrunschwig

[Approval Request Comment]
Regression caused by (bug #): none
User impact if declined: some correspondents cannot decrypt email sent by Thunderbird
Testing completed (on c-c, etc.): manually
Risk to taking this patch (and alternatives if risky): low risk

Comment 13

[Kai Engert [:KaiE:]]

(In reply to Kai Engert (:KaiE:) from comment #10)

(In reply to Kosuke Kaizuka from comment #9)

Is this patch effective for both encryption and signing ... ?

yes, it should

I realize I was wrong. I've only modified function getSuitableSubkey(). But if the primary is already found to be usable, then we don't call getSuitableSubkey().

Usually the primary key isn't allowed to be used with encryption. That means this patch helps in the common scenario.

In the unusual scenario that the primary key is allowed to be used for encryption, this patch doesn't change anything, we'd still use the primary key.

For signing, because the usual scenario is that the primary key may be used for signing, this patch doesn't help yet.

A more complete patch needs to check for newer subkeys, regardless of the allowance settings of the primary key.

Comment 14

[Kai Engert [:KaiE:]]

Comment on attachment 9177744 [details]
Bug 1665281 - Encrypt to most recently created OpenPGP encryption subkey. r=PatrickBrunschwig

removing approval requests, I'd like to work on a better patch.

Comment 15

[Kai Engert [:KaiE:]]

Note that in the following scenario we'd have to ignore the suggested "use newer subkey" rule:

• primary key created in 2015 and expires in 2021 (or never)
• subkey created in 2018 and expired in 2019
  then in the year 2020, we'd ignore the newer subkey, and use the primary key.

Comment 16

[Kosuke Kaizuka]

(In reply to Kai Engert (:KaiE:) from comment #15)

Note that in the following scenario we'd have to ignore the suggested "use newer subkey" rule:

• primary key created in 2015 and expires in 2021 (or never)
• subkey created in 2018 and expired in 2019
  then in the year 2020, we'd ignore the newer subkey, and use the primary key.

That's the case, of course.
To be accurate, "use the newest usable (neither revoked nor expired) subkey".

Comment 17

[Kai Engert [:KaiE:]]

Attachment: Bug 1665281 - Follow-up, always check subkeys, even if primary key is usable. r=PatrickBrunschwig

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/48906d492bc5
Follow-up, always check subkeys, even if primary key is usable. r=PatrickBrunschwig DONTBUILD

Comment 19

[Kai Engert [:KaiE:]]

Comment on attachment 9177744 [details]
Bug 1665281 - Encrypt to most recently created OpenPGP encryption subkey. r=PatrickBrunschwig

[Approval Request Comment]
Regression caused by (bug #): none
User impact if declined: some correspondents cannot decrypt email sent by Thunderbird
Testing completed (on c-c, etc.): manually
Risk to taking this patch (and alternatives if risky): low risk

Comment 20

[Wayne Mery (:wsmwk)]

Comment on attachment 9177744 [details]
Bug 1665281 - Encrypt to most recently created OpenPGP encryption subkey. r=PatrickBrunschwig

[Triage Comment]
Approved for esr78
Approved for beta

Comment 21

[Wayne Mery (:wsmwk)]

Comment on attachment 9178201 [details]
Bug 1665281 - Follow-up, always check subkeys, even if primary key is usable. r=PatrickBrunschwig

[Triage Comment]
Approved for esr78
Approved for beta

Comment 22

[Kai Engert [:KaiE:]]

82.0b2
https://hg.mozilla.org/releases/comm-beta/rev/46fd715d2362fefbb30b089a37bdbabf0b5a68d9
https://hg.mozilla.org/releases/comm-beta/rev/457266119c3be535bd89c7d878a00eab7c1be2df

Comment 23

[Kai Engert [:KaiE:]]

78.3.2
https://hg.mozilla.org/releases/comm-esr78/rev/2a0b8cd4e831f27bda0b53d8996069db06916212
https://hg.mozilla.org/releases/comm-esr78/rev/670d9489ef51a6ca4e8f044d91d2c1d2e53a5a2d

Comment 24

[Kosuke Kaizuka]

Confirmed with 78.3.2 (auto-updated today), both signing and encryption with the newest subkey work fine.