Closed Bug 1665281 Opened 2 years ago Closed 2 years ago

Tb-native OpenPGP implementation does not use newer subkeys

Categories

(MailNews Core :: Security: OpenPGP, defect)

defect

Tracking

(thunderbird_esr78 fixed, thunderbird82 fixed)

RESOLVED FIXED
83 Branch
Tracking Status
thunderbird_esr78 --- fixed
thunderbird82 --- fixed

People

(Reporter: cai.0407, Assigned: KaiE)

References

Details

Attachments

(2 files)

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)

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

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.

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?

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

Duplicate of this bug: 1665685
Assignee: nobody → 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).

See Also: → 1667232
Status: UNCONFIRMED → NEW
Ever confirmed: true

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?

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

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/8fc4a078751c
Encrypt to most recently created OpenPGP encryption subkey. r=PatrickBrunschwig DONTBUILD

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

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

Attachment #9177744 - Flags: approval-comm-esr78?
Attachment #9177744 - Flags: approval-comm-beta?

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

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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.

Attachment #9177744 - Flags: approval-comm-esr78?
Attachment #9177744 - Flags: approval-comm-beta?

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.

(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".

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/48906d492bc5
Follow-up, always check subkeys, even if primary key is usable. r=PatrickBrunschwig DONTBUILD

Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED

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

Attachment #9177744 - Flags: approval-comm-esr78?
Attachment #9177744 - Flags: approval-comm-beta?
Attachment #9178201 - Flags: approval-comm-esr78?
Attachment #9178201 - Flags: approval-comm-beta?

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

Attachment #9177744 - Flags: approval-comm-esr78?
Attachment #9177744 - Flags: approval-comm-esr78+
Attachment #9177744 - Flags: approval-comm-beta?
Attachment #9177744 - Flags: approval-comm-beta+

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

Attachment #9178201 - Flags: approval-comm-esr78?
Attachment #9178201 - Flags: approval-comm-esr78+
Attachment #9178201 - Flags: approval-comm-beta?
Attachment #9178201 - Flags: approval-comm-beta+

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

You need to log in before you can comment on or make changes to this bug.