1847703 - (smime-2023) Track S/MIME functionality that's recommended in 2023 but missing in Thunderbird

Status: NEW

(MailNews Core :: Security: S/MIME, enhancement)

Description

[Kai Engert (:KaiE:)]

The S/MIME code in Thunderbird hasn't seen much attention in past years.
I assume our implementation isn't up to date with regards to latest specifications and expectations.

I suggest to research what's missing.

We should discuss which improvements/changes are important, necessary, or optional.

Comment 1

[Kai Engert (:KaiE:)]

Is it necessary to support RSA-OAEP ?
see bug 215997 and bug 1826086

Comment 2

[Kai Engert (:KaiE:)]

Some existing bugs that request support for RFCs related to S/MIME:

• bug 1078725
• bug 1673177
• bug 1735762

Comment 3

[Anna Weine]

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

Is it necessary to support RSA-OAEP ?
see bug 215997 and bug 1826086

I would have gone straight to RSA-PSS.

Comment 4

[Kai Engert (:KaiE:)]

More bugs:

• bug 1597202
• bug 1833215
• bug 1835697
• bug 1836849
• bug 676118

Comment 5

[Kai Engert (:KaiE:)]

(In reply to Anna Weine from comment #3)

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

Is it necessary to support RSA-OAEP ?
see bug 215997 and bug 1826086

I would have gone straight to RSA-PSS.

Is RSA-OAEP for encryption, and RSA-PSS for signing?

Comment 6

[Hubert Kario]

RSA-PSS is for signing messages, RSA-OEAP is for encrypting messages

while supporting RSA-PSS is nice, RSA-PKCS#1 v1.5 signing algorithm isn't broken or hard to use safely, so migrating to RSA-PSS it is just a matter of good hygiene

RSA-PKCS#1 v1.5 encryption algorithm is truly horrible, and we get CVEs related to it (algorithm, not implementation in NSS) nearly every year. It absolutely should have not been used good 10 years ago. The only replacement for it is the RSA-OAEP algorithm.

Comment 7

[leszek.zablocki]

Attachment: bitch-stewie.jpg

S/MIME specification causes a lot of confusion about the algorithms used, therefore, I wrote 3 scripts (separately for RSA, NIST EC and DSA+DH certificates) that create emails in different cryptographic configurations. For information on how to import these emails, see my other bug issues (AES-GCM for e.g.). The summary is in .csv spreadsheet files. These are probably not all the algorithms that NSS/Th. can read.

We should discuss which improvements/changes are important, necessary, or optional.

2 things that I think are necessary.

1. Th. should display information about the algorithms used to encrypt/sign the message (for enc RSA: keyEncryptionAlgorithm / parameters / contentEncryptionAlgorithm, for sig RSA: signatureAlgorithm / parameters / digestAlgorithm, for enc NIST EC: keyAgreementAlgorithm / keyWrapAlgorithm / contentEncryptionAlgorithm, for sig NIST EC: signatureAlgorithm / digestAlgorithm, DSA+DH turned off), and a combination of algorithms for a message first signed, then encrypted (information for different layers). Related bugs: bug#130633, bug#134208, bug#136512, bug#229724. Programs such as Outlook, eM Client have supported such a feature for years. By the way, it would be useful to know on the Thunderbird site what algorithms are supported (inventory).

2. Th. should have settings for message encryption/signing algorithms. Related bugs: bug#136289, bug#222179#c34. This is where things get very complicated. Outlook, for example, has a global configuration of cryptographic preferences (order of algorithms): before sending an email, the program checks in the recipient's last message cryptographic capabilities and, according to our order settings, sends the message with the appropriate encryption, see bug#1833230. Alternatively, our settings may take precedence over those of the recipient. This solution is, in my opinion, the most appropriate. It would be necessary to create 2 separate global preferences (for RSA and NIST EC keys, in the future for other keys), or a unified configuration for all types of keys, create a database of cryptographic capabilities from recipient messages, etc. The second, additional option is to set the encryption/signature parameters for each new message separately (the default settings are from our cryptographic preference configuration).

https://bugzilla.mozilla.org/show_bug.cgi?id=222179#c59 :

I can't rule out the possibility that something like this will happen in the future. There may at some point be a transition to yet another set of algorithms, and there will be a need to choose between the current algorithms (supported by all clients) and the newer, stronger algorithms (not yet supported by everyone), but I don't see anything like that happening anytime soon.

These two issues can be fixed before additional difficulties are introduced. Solutions may come from competitors. Perhaps these solutions could be ported to OpenPGP? (related: bug#1638457, bug#1662581, bug#1669654, bug#1681938, bug#1630433, bug#1595226, bug#1595227, bug#1666634)

https://datatracker.ietf.org/doc/html/rfc8551#section-2.7.1 :

   When a sending agent creates an encrypted message, it has to decide
   which type of encryption to use.  The decision process involves using
   information garnered from the capabilities lists included in messages
   received from the recipient, as well as out-of-band information such
   as private agreements, user preferences, legal restrictions, and
   so on.

https://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-sha3-hash-00.txt#section-5 :

   Implementers should be aware that cryptographic algorithms become
   weaker with time.  As new cryptanalysis techniques are developed and
   computing performance improves, the work factor to break a particular
   cryptographic algorithm will reduce.  Therefore, cryptographic
   algorithm implementations should be modular allowing new algorithms
   to be readily inserted.  That is, implementers should be prepared to
   regularly update the set of algorithms in their implementations.

Regarding the above improvements:

• RSAES-OAEP & RSASSA-PSS -- see comment above
• AES-GCM / AES-CCM / ChaCha20-Poly1305 -- AEAD against Efail. No email program (except openssl cms?) supports this.
• Ed25519/Ed448 and X25519/X448 -- no email program supports it (not even openssl). Th. can't handle importing such certificates.

In any case, it is best to deal with the implementation of improvements that can be tested in practice in openssl (encrypt in openssl cms and decrypt in Th. and vice versa)

Of the needed improvements: I wouldn't underestimate the research workers, for example, bug#1243449, I would analyze each page and address each error indicated (usability). Equally important is the research papers on Efail.

Links:

• Evolution of Email Security Standards - Russell Housley 2022
• NSS project page > S/MIME Toolkit
• Federal S/MIME V3 Client Profile - 2002
• Recommendations and Key Lengths Version: 2023-1

--

(advertisement)

I finally took the time to take all the test scripts and put them in a repo. I have also added the specification of certificates.

Comment 8

[leszek.zablocki]

Attachment: SMIME_DSA_and_DH_stress-test.tar.gz

Comment 9

[leszek.zablocki]

Attachment: SMIME_RSA_stress-test.tar.gz

Comment 10

[leszek.zablocki]

Attachment: SMIME_nistEC_stress-test.tar.gz

Comment 11

[Hubert Kario]

one thing I remembered now: Active Directory certificates, at least the host ones, by default now use RSA-PSS signatures, I'd be surprised if user certs were any different, so that may be a big reason to support RSA-PSS in general (at least for verification)

Comment 12

[leszek.zablocki]

bug#215997#c3:

I've been told that NIST has deprecated the RSA PKCS#1 v1.5 padding for encryption.
Support for RSA-OAEP is necessary for compliance and compatibility with other email clients.

· ETSI ESI Cryptographic Suites 2023-08

I have looked at other specifications (than the US ones) and the ETSI ones are very practical. Go to the "www.etsi.org" website and type "ESI" into the search engine. They have developed specifications analogous to S/MIME (CadES/PadES).

For comparison, the European Commission's eIDAS eID profile (oh those bureaucrats...):

· eIDAS Cryptographic Requirement v.1.2 Final.pdf August 2019

Comment 13

[Kai Engert (:KaiE:)]

I now have a better understanding of the current state and missing functionality, and would like to provide the following summary and suggestions.

S/MIME Email encryption using ECC keys and NIST curves:

We have recently added support for ECDH to NSS (both encryption and decryption, bug 1892223 and bug 676118).
As a result, the next Thunderbird ESR 128 (summer 2024) will be able to work with ECC certificates.

S/MIME Email encryption using the better RSA-OAEP algorithm.

Very soon we should be able to support DEcryption of RSA-OAEP, also targetting the ESR 128 release (bug 215997).

To make it easier for users to obtaining certificates with a secret key and CSR generated on their own computer, I'd like to attempt to fix bug 1581796 in time for the ESR 128 release.

For the summer 2025 release the next steps are:

• we should add support for RSA-OAEP ENcryption (NSS bug 1892671, also TB bug 1826086)

• to ensure TB can correcty decide when to use classic RSA or RSA-OAEP, it needs to properly hande the S/MIME capability flags in incoming messages, and also send out correct flags that tell correspondents what Thunderbird supports (bug 1892672)

• we should improve our symmetric encryption algorithm by supporting GCM (bug 1835697)

• ensure we use the appropriate symmetric algorithm when sending out encrypted messages, prefer GCM, and use CBC or 3DES only when absolutely necessary, I assume this will also require capability flag.

• we need some kind of user interface feedback that allows the user to learn which algorithms were used in a given message.

• add support for verifying (high priority) RSA-PSS signatures, and for creating them (lower priority)
  (NSS bug 1597202 and TB bug 1597202)

Comment 16

[Kai Engert (:KaiE:)]

Adding support for Ed25519/Ed448 and X25519/X448 (bug 1833215) seems to have lower priority than the items from comment 13.

Comment 17

[Hubert Kario]

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

Adding support for Ed25519/Ed448 and X25519/X448 (bug 1833215) seems to have lower priority than the items from comment 13.

agreed, RSA-PSS and RSA-OAEP are defaults for S/MIME in AD environments, Edwards curves support are the least of the problems.

Comment 18

[Kai Engert (:KaiE:)]

In addition to the items we already mentioned above, there's another diligence job that needs to be done:
Carefully read all the latest RFCs, and identify where TB's behavior isn't matching.