Thunderbird S/MIME: Interoperability problem with gpgsm (KMail / Claws Mail)
wurstsemmel
Mr. Rod Whiteley from the MozillaZine Thunderbird Forums gave me the
hint to bring up my questions in this newsgroup.
We experienced, that Tb uses the algorithm RC2 if you send a S/MIME
encrypted eMail to KMail. KMail (and Claws Mail) use gpgsm to handle the
S/MIME mails. In gpgsm the RC2 algorithm is not implemented for patent
reasons.
The behavior of Tb arises from its handling of the S/MIME capabilities.
KMail requests an algorithm (I think AES), which Tb does not support. In
this case Tb seems to fall back to RC2.
Tb uses 3DES (which it normally does - communicating with other Tb), if
you import the certificate manually. As soon as you reply to a KMail
eMail by using the "Reply" - button it uses RC2 again.
Are there about:config entries for at least one of the following
proposed solutions:
a) Disable RC2 in Tb.
b) Set the default fallback to 3DES.
c) Switch on AES.
d) disable interpreting of "smimecapabilities"
The original thread is at
http://forums.mozillazine.org/viewtopic.php?p=2858116#2858116
Interesting readings: http://kb.mozillazine.org/Message_security and
http://www.mozilla.org/projects/security/pki/nss/nss-3.11/nss-3.11-algorithms.html
In http://www.gossamer-threads.com/lists/gnupg/devel/40286 and
http://www.gossamer-threads.com/lists/gnupg/devel/40396 "wk at gnupg"
stated, that it is not a problem of gpgsm.
**_He thinks, that this is a bug in Tb, which should be fixed._**
The keys mentioned by "patrick at mozilla-enigmail" are set to false (by
default).
Thank you very much for your help,
wurstsemmel
Paul Hoffman
>Now technically KMail MUST implement RC2-40 (is the implementers
>confusing RC2 with RC5?) according to the S/MIME spec (all
>implementations must support RC2-40. All strong implementations must
>support 3DES).
. . .
>4. The S/MIME spec requires accepting RC2-40 by all S/MIME implementations.
Not true. RFC 3851 is very, very careful about this. [[ Disclaimer: I
helped write a lot of the language in this part of the spec. ]]
Section 2.7 says:
Sending and receiving agents MUST support encryption and decryption
with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG].
Receiving agents SHOULD support encryption and decryption using the
RC2 [CMSALG] or a compatible algorithm at a key size of 40 bits,
hereinafter called "RC2/40". Sending and receiving agents SHOULD
support encryption and decryption with AES [CMSAES] at a key size of
128, 192, and 256 bits.
SHOULD != MUST.
Further, section 2.7.2 says:
2.7.2. Choosing Weak Encryption
Like all algorithms that use 40 bit keys, RC2/40 is considered by
many to be weak encryption. A sending agent that is controlled by a
human SHOULD allow a human sender to determine the risks of sending
data using RC2/40 or a similarly weak encryption algorithm before
sending the data, and possibly allow the human to use a stronger
encryption method such as tripleDES.
>In practice the number of weak implementations out there has
>declined, so we may want to rethink our defaults in NSS to be 3DES
>unless we have some hint the recipient is a weak client.
Let's start that rethinking now. The only reason to support RC2/40
for encryption is to send to a receiver that does not support any of
the strong algorithms you know. There are essentially zero
applications for which this is true.
Proposal:
a) Completely turn off the ability to encrypt with RC2/40 unless
there is no strong algorithm.
b) Every time you are about to encrypt with RC2/40, warn the user,
including an explanation of how Tb got to this point in the logic
chain.
wurstsemmel
thanks for your fast reply. Before I can write the bug report, I should
somehow verify, that KMail is definitely requesting AES.
I should add, that MS OE shows 3DES as "preferred algorithm from the
sender" (sorry, this is translated from the German localized OE
version), if you send an eMail from Tb. If you send an eMail from KMail
to MS OE, it shows *40.1.101.3.4.1.2 as "preferred algorithm from the
sender" I think that this number corresponds to AES, but my only (weak)
proof is
http://lists.iaik.tugraz.at/pipermail/jce-general/2001-August/001348.html.
> There are several separate issues here:
>
> 1) NSS is not matching on AES. - This is the biggest issue.
> 2) For some reason NSS is not negotiating 3DES (is KMail sending 3DES in
> the profile. If not, that's a KMail bug).
How to have a look in this profile?
> 3) We probably should have a single button to disable weak crypto (which
> would disable RC2-40), or better yet disable it by default.
Sounds very good.
Am I right, that I should write the bug report on 1). What about 3),
shall I write a 2nd bug report?
> Now technically KMail MUST implement RC2-40 (is the implementers
> confusing RC2 with RC5?)
I don't think so, they speak about "40 bit RC2"
> according to the S/MIME spec (all
> implementations must support RC2-40. All strong implementations must
> support 3DES). In practice the number of weak implementations out there
> has declined, so we may want to rethink our defaults in NSS to be 3DES
> unless we have some hint the recipient is a weak client.
This would correspond to point 3).
> 1. Disabling weak crypto by default is a decision we should make
> independent of KMail interoperability.
> 2. If KMail is sending AES in the profile, NSS should be using it.
> (potential AES bug).
> 3. It looks like KMail is not sending all of it's profile information,
> particularly 3DES (KMail bug).
> 4. The S/MIME spec requires accepting RC2-40 by all S/MIME
> implementations. KMail clearly falls down there.
Once more to be sure: 1. and 2. should be mentioned in 2 bug reports?
> KMail will face the same interoperability problems with OE, which runs
> home to RC2-40 much more often than NSS...
The problems with OE are the same!
> (BTW, if you put TB in FIPS mode, does the problem go away?)
Unfortunately not.
Bye,
wurstsemmel
Nelson Bolyard
> thanks for your fast reply. Before I can write the bug report, I should
> somehow verify, that KMail is definitely requesting AES.
>
> I should add, that MS OE shows 3DES as "preferred algorithm from the
> sender" (sorry, this is translated from the German localized OE
> version), if you send an eMail from Tb. If you send an eMail from KMail
> to MS OE, it shows *40.1.101.3.4.1.2 as "preferred algorithm from the
> sender" I think that this number corresponds to AES,
Googling for 2.16.840.1.101.3.4.1.2 reveals it is id-aes128-CBC.
See <http://www.alvestrand.no/objectid/2.16.840.1.101.3.4.1.2.html>
NSS knows about this OID, with a symbol named SEC_OID_AES_128_CBC
But it doesn't appear to be USED anywhere in libSMIME. See
<http://mxr.mozilla.org/security/search?string=SEC_OID_&find=smime%2F&findi=&filter=&tree=security>
It needs to be added to this table:
<http://mxr.mozilla.org/security/source/security/nss/lib/smime/smimeutil.c#146>
and perhaps elsewhere.
>> There are several separate issues here:
>>
>> 1) NSS is not matching on AES. - This is the biggest issue.
>> 2) For some reason NSS is not negotiating 3DES (is KMail sending 3DES
>> in the profile. If not, that's a KMail bug).
>
> How to have a look in this profile?
NSS's "pp" (pretty print) program will decode it from a PKCS#7 message.
You could send me a signed message from that KMail tool, and I could show
you what NSS sees in it. (With your permission, I'd post the output to
this list.) (Remove NO and SPAM from my email address shown above.)
> Am I right, that I should write the bug report on 1). What about 3),
> shall I write a 2nd bug report?
Surely. File bugs. There is a Google Summer-of-code student who is
planning on working on NSS's libSMIME this summer. I think this is
one of the things on his list, but if you file a bug on it, it won't
get forgotten.
>> 1. Disabling weak crypto by default is a decision we should make
>> independent of KMail interoperability.
>> 2. If KMail is sending AES in the profile, NSS should be using it.
>> (potential AES bug).
libSMIME bug.
>> 3. It looks like KMail is not sending all of it's profile information,
>> particularly 3DES (KMail bug).
>> 4. The S/MIME spec requires accepting RC2-40 by all S/MIME
>> implementations. KMail clearly falls down there.
Yes, IMO these last two points are clearly KMail issues.
> Once more to be sure: 1. and 2. should be mentioned in 2 bug reports?
Don't file a bug on 2 until you (we) have proof that KMail is including
3DES in the profile.
>> KMail will face the same interoperability problems with OE, which runs
>> home to RC2-40 much more often than NSS...
>
> The problems with OE are the same!
Well, that points pretty strongly at KMail then.
Nelson Bolyard
> Proposal:
> a) Completely turn off the ability to encrypt with RC2/40 unless there
> is no strong algorithm.
> b) Every time you are about to encrypt with RC2/40, warn the user,
> including an explanation of how Tb got to this point in the logic chain.
Patches cheerfully received. :)
Paul Hoffman
Thought there should be some conversation first...
Jean-Marc Desperrier
> Paul Hoffman wrote:
>> Proposal:
>> a) Completely turn off the ability to encrypt with RC2/40 unless there
>> is no strong algorithm.
What do you mean here ? RC2/40 will already be choosen only if TB
believe (wrongly in that case) there's nothing else available.
It could do the same as Fx 2.0 for ssl, where rc2/40 is disabled by
default but can be reenabled with a hidden option if you *really* need
it. 56 bits receives the same treatment.
>> b) Every time you are about to encrypt with RC2/40, warn the user,
>> including an explanation of how Tb got to this point in the logic chain.
That's what the navigator used to do for 40 bits encryption in the past
(but without much explanation).
Nelson Bolyard
>>> There are several separate issues here:
>>>
>>> 1) NSS is not matching on AES. - This is the biggest issue.
>>> 2) For some reason NSS is not negotiating 3DES (is KMail sending 3DES
>>> in the profile. If not, that's a KMail bug).
>> How to have a look in this profile?
>
> NSS's "pp" (pretty print) program will decode it from a PKCS#7 message.
>
> You could send me a signed message from that KMail tool, and I could show
> you what NSS sees in it. (With your permission, I'd post the output to
> this list.) (Remove NO and SPAM from my email address shown above.)
> Don't file a bug on 2 until you (we) have proof that KMail is including
> 3DES in the profile.
Today I received a signed mail from a KMail user whose name I have not
seen before. The message did not mention this thread, so I'm guessing,
but I suspect it was from user wurstsemmel.
Using pp, I looked at the signature. Here's part of what I found:
Signer Information List:
Signer Information (1):
Version: 1 (0x1)
Issuer: "E=sup...@cacert.org,CN=CA Cert Signing Authority,OU
=http://www.cacert.org,O=Root CA"
Serial Number: 228686 (0x37d4e)
Digest Algorithm: SHA-1
Authenticated Attributes:
Attribute (1):
Type: PKCS #9 Content Type
Value (1): PKCS #7 Data
Attribute (2):
Type: PKCS #9 Signing Time
Value (1): Mon Apr 30 16:39:49 2007
Attribute (3):
Type: PKCS #9 Message Digest
Value (1):
64:23:d9:3e:71:7b:5b:11:66:6b:4c:0d:bf:da:a9:03:
16:8d:58:9c
Attribute (4):
Type: PKCS #9 S/MIME Capabilities
Value (1) (encoded): Sequence {
Sequence {
AES-128-CBC
NULL
}
Sequence {
DES-EDE3-CBC
NULL
}
}
So, there we see that KMail did identify itself as being capable of
receiving messages encrypted with either AES-128-CBC or DES-EDE3-CBC.
After receiving such a message, I would expect a mozilla mail client
such as ThunderBird or SeaMonkey to send an encrypted message using
DES-EDE3-CBC. After doing so, if KMail was then found to be unable
to decrypt the message, I'd suspect that is KMail's problem.
I will send an encrypted reply to the email I received. We'll see if
my correspondent can decrypt it.
/Nelson
Nelson B
> I will send an encrypted reply to the email I received. We'll see if
> my correspondent can decrypt it.
I remembered that mozilla doesn't "import" (save) an encryption cert
from an email unless it can validate that cert. That means the cert
has to have been issued by a trusted issuer. So, I set the email trust
bit on the CACert root CA, and then read the message, and THEN mozilla
imported his cert and it appeared in Cert Manager.
Then I replied to the message with a signed and encrypted reply.
After sending it, I looked at the message I had just sent, and saw this:
SEQUENCE {
OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) (PKCS #7)
SEQUENCE {
OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
SEQUENCE {
INTEGER 160
OCTET STRING 3B EE E9 74 FF FE 87 90
}
}
Which tells me that mozilla sent an rc2 encrypted reply. :(
So, indeed, something seems wrong with mozilla's SMIME code here
(in NSS or PSM). Given that the KMail message offered to receive
either 3DES or AES, and mozilla supports 3DES, mozilla should have
sent a 3DES reply.
--
Nelson B
Martin Hoefling
Hi Nelson and others...
> Nelson Bolyard wrote:
>
>> I will send an encrypted reply to the email I received. We'll see if
>> my correspondent can decrypt it.
Just to reduce confusion about my mail: I am Martin Hoefling (using
KMail/Kontact), and Wurstsemmel is using Thunderbird. We encountered the
problems, while testing communication via S/Mime certificates.
As far as we understood, this is a thunderbird issue. Who should file a
bugreport? Shall we do it?
We can test, the patch, if a communication partner with KMail is needed.
Cheers
Martin
Nicholas Sushkin
disable RC2/40 - "S/MIME should not support weak crypto"
(https://bugzilla.mozilla.org/show_bug.cgi?id=84213)
Also, here's a thread in which author of gpgsm Werner Koch explains why he
doesn't support RC2 and what he thinks about Thunderbird implementation.
http://www.nabble.com/gpgsm-1.9.22-supports-no-RC2-Algorithm---tf3581426.html
Also, I am using KMail with gpgsm and Thunderbird when I can't decrypt using
KMail. So, if anyone needs testing, I can help.
Thanks.
Paul Hoffman wrote:
--
Nick
Nelson Bolyard
> Martin Hoefling wrote:
>> Just to reduce confusion about my mail: I am Martin Hoefling (using
>> KMail/Kontact), and Wurstsemmel is using Thunderbird. We encountered the
>> problems, while testing communication via S/Mime certificates.
>>
>> As far as we understood, this is a thunderbird issue. Who should file a
>> bugreport? Shall we do it?
>>
> file the bug at bugzilla.mozilla.org New->Other Products->NSS
>
> We don't know if it's PSM or NSS, but at this point I think NSS picks
> the cipher, so start there.
I filed Bug 379625 – Encrypting with RC2-40 when 3DES is preferred
on this issue. Product: Core, Component: Security:S/MIME
We can change it to NSS if & when we've identified the cause to be NSS.
All interested parties should add themselves to the CC list of that bug.
> Nelson's experiment clearly exonerates KMail.
I'm not entirely sure of that yet.
I found that KMail is encoding its encryption preferences for fixed key
size ciphers (such as 3DES) differently from the way that NSS does it.
I suspect that NSS is having troubles decoding KMail's encoding of
the cipher preferences, for this reason. See the bug for details.
The question is: is KMail's encoding allowed by the standard?
Or it is wrong? (Or is NSS's wrong?)
Probably NSS should ALLOW KMail's encoding, whether it is strictly
by the standards or not.
> bob
>> We can test, the patch, if a communication partner with KMail is needed.
Thanks for that offer. I'm sure we will want you to help test it.
/Nelson
Nicholas Sushkin
> Now technically KMail MUST implement RC2-40 (is the implementers
> confusing RC2 with RC5?) according to the S/MIME spec (all
> implementations must support RC2-40.
I read the S/MIME spec differently. Quoting Section 2.7 from
http://www.apps.ietf.org/rfc/rfc3851.html#sec-2.7
2.7 ContentEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support encryption and decryption with DES
EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Receiving agents SHOULD
support encryption and decryption using the RC2 [CMSALG] or a compatible
algorithm at a key size of 40 bits, hereinafter called "RC2/40". Sending
and receiving agents SHOULD support encryption and decryption with AES
[CMSAES] at a key size of 128, 192, and 256 bits.
--
Nick
Nicholas Sushkin
problem in how gpgsm encoded cipher preferences. Thunderbird crypto library
was made more lenient in what it accepted. So, now, TB would correctly
responds to KMail using 3DES instead of RC/40.
See https://bugzilla.mozilla.org/show_bug.cgi?id=379625
Not sure when this fix will make it to a release.
Still unresolved:
* support of AES by Thunderbird
https://bugzilla.mozilla.org/show_bug.cgi?id=379753
* Thunderbird should not support weak crypto
https://bugzilla.mozilla.org/show_bug.cgi?id=84213
* correct generation of SMimeCapabilities by gpgsm
http://www.intevation.de/roundup/aegypten/issue754
* GPGSM does not recognize Verisign certs because of MD2 hash algo
http://www.intevation.de/roundup/aegypten/issue430
--
Nick
Claudio Shah
thank you very much for all the work! I am impressed, how fast and
accurate you guys are working.
> * support of AES by Thunderbird
> https://bugzilla.mozilla.org/show_bug.cgi?id=379753
Great, I was thinking about filing this bug, but it is already done!
Bye,
Claudio (aka wurstsemmel)
Alaric Dailey
Now if we could just fix the problem with not finding the correct certs...
https://bugzilla.mozilla.org/show_bug.cgi?id=278689
https://bugzilla.mozilla.org/show_bug.cgi?id=248907
Since they have been bugs since 2004! In ALL Mozilla products.
Hi Nicholas, hi Nelson,
Bye,
Claudio (aka wurstsemmel)
_______________________________________________
dev-tech-crypto mailing list
dev-tec...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto