1167857 - Thunderbird should use AES for S/MIME based on correspondent's key sizes, for compliance with RFC 5751

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Anton]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0

Steps to reproduce:

At first: Many thanks for keeping Thunderbird alive.
----
The latest version does not fully comply with RFC 5751 regarding the S/MIME settings.
I sent S/MIME encrypted emails from Outlook 2010 v14.0.7149  to Thunderbird 31.7, 38, 40 and Seamonkey 2.33, 2.38, requesting in the attribute "SMIMECapabilities" the encryption with AES 256 and the hash SHA512.
I replied to these emails with TB and SM, and checked the applied encryption and hashes in Outlook. There it is possible to set the demanded and display the applied encryption and hashes.
Machines used for check: Mac OS X with TB 31, Linux i386 with all clients.


Actual results:

TB 31 applied always 3DES for content encryption and SHA1 for hashing. TB 38, 40 and SM 2.33, 2.38 used 3DES and SHA256.


Expected results:

Following RFC 5751 the responding clients should use the settings demanded by the sender. In case of an erroneous or missing S/MIME attribute from Outlook ("unknown capabilities") AES 128 should have been applied.

All results and the relevant RFC sections are stored here:
https://github.com/CryptoPartyGraz/Vortraege/tree/master/S-MIME_settings_Thunderbird

Comment 1

[Ludovic Hirlimann [:Usul]]

SHA-1 is being retired and removed because it's two weak.

Comment 2

[Paul Wiener]

I also thank all the programmers for working on Thunderbird.

Regarding this bug I'd like to know whether someone will work on this? It is confirmed that SHA-1 is weak and it looks as if Thunderbird is now using SHA-256 (solved in 1018259).

But what about 3DES? This is also not state of the art. Microsoft Outlook is using AES-256 for encryption. Wouldn't it be fine to also have AES-256 as default?

Comment 3

[Kent James (:rkent)]

Currently there are no active developers who are focused on actively improving S/MIME functionality in Thunderbird. If there is an issue of serious concern, then we would try to motivate someone who works more broadly to try to address it. But "does not fully comply" is not a high enough bar.

Contributors and patches are welcome.

Comment 4

[Ruben]

This is still the case in Thunderbird 45.

I tried sending an email to myself and found out, that the selected encryption for my email was still 3DES (which is broken).

On https://lapo.it/asn1js/ you can paste the encrypted email text part (from the source Ctrl+U below "Content-Description: S/MIME Encrypted Message") and see the decrypted details (  for example https://mcaf.ee/fnt3kr )

There you find the string

    OBJECT IDENTIFIER1.2.840.113549.3.7des-EDE3-CBC

which shows that 3DES is used.

A secure encryption like AES, camelia, aria or chacha20 shouldh have been selected to encrypt my mail body.

Comment 6

[David Cooper]

Attachment: Patch to make AES the symmetric encryption algorithm

This patch modifies smime_choose_cipher() so that in the normal case AES will be used as the symmetric encryption algorithm.

While the code in smime_choose_cipher() is quite out-of-date, and could use a general update, this patch makes the smallest change to the code necessary to make the switch from 3DES to AES.

With this patch, AES-128 will be used as long as all recipients have RSA keys that are at least 1024-bits in length. If all recipients have RSA keys that are longer than 3072 bits, then AES-256 is used.

In addition to making Thunderbird compliant with RFC 5751, this change has been requested in this bug report, in bug #1364568 and in bug #222179 comment 58. In addition, Robert Relyea noted in bug #676108 comment #4 that the default symmetric encryption algorithm for RSA should be switched to AES.

Comment 7

[Robert Relyea]

Comment on attachment 9023715 [details] [diff] [review]
Patch to make AES the symmetric encryption algorithm

Review of attachment 9023715 [details] [diff] [review]:
-----------------------------------------------------------------

r+ rrelyea
David, do you have checkin privellege to NSS? If not let me know and I'll check the patch in.

bob

Comment 8

[David Cooper]

(In reply to Robert Relyea from comment #7)
> David, do you have checkin privellege to NSS? If not let me know and I'll
> check the patch in.

Thanks for reviewing this patch. To the best of my knowledge, I do not have checkin privileges.

Comment 9

[Kai Engert [:KaiE:]]

The relevant change is inside the NSS library, so I'm changing this one to a NSS bug.

Checked in:
https://hg.mozilla.org/projects/nss/rev/6a7534a8b518

Thunderbird will get this change when it picks up a newer Mozilla core with NSS 3.42

Comment 10

[Magnus Melin [:mkmelin]]

(In reply to Kai Engert (:kaie:) from comment #9)

Thunderbird will get this change when it picks up a newer Mozilla core with NSS 3.42

I assume we picked this up by now? So this is fixed?

Comment 11

[David Cooper]

(In reply to Magnus Melin [:mkmelin] from comment #10)

(In reply to Kai Engert (:kaie:) from comment #9)

Thunderbird will get this change when it picks up a newer Mozilla core with NSS 3.42

I assume we picked this up by now? So this is fixed?

I just tried sending an encrypted message using Thunderbird 68.2.0 and it was encrypted using AES-128 CBC. So, it seems that the patch I submitted has been picked up. However, the original comment was about following the SMIMECapabilities of the recipient, and my patch did nothing about that.

In addition, it seems that my patch is already out of date. Section 2.7.1.2 of RFC 5751 recommends using AES-128 CBC if the capabilities of the recipient are unknown, and this is what my patch does if the recipient has an RSA key of 3072-bits or less. However, I just discovered that RFC 5751 was obsoleted by RFC 8551 in April 2019, and Section 2.7.1.2 of RFC 8551 says that AES-256 GCM SHOULD be used if the sender has no knowledge of the capabilities of the recipient. It does, however, also say:

If the sending agent chooses not to use AES-256 GCM in this step,
given the presumption is that a client implementing AES-GCM would do
both AES-256 and AES-128, it SHOULD use AES-128 CBC.

So, AES-128 CBC is still deemed acceptable, but moving to AES-256 GCM should be considered. I haven't done any testing, so at the moment I don't even know whether Thunderbird could decrypt a message that was encrypted using AES GCM, and if it can, I don't know what would be required to modify it to use AES GCM to encrypt messages.

Comment 12

[matze112]

I just want to say: THANK YOU!

It made me very happy today to see that someone still cares about privacy and that Thunderbird has gotten this update. That's really a great sign after too many years of stagnation in this area of Thunderbird.

Comment 13

[Magnus Melin [:mkmelin]]

This landed long ago (comment 9).,