Re: S/MIME in Thunderbird
On 2010-03-05 15:58 PST, Wan-Teh Chang wrote: > On Wed, Mar 3, 2010 at 4:05 AM, Jean-Marc Desperrier wrote: >> TLS depends on the cipher-suites, and fortunately it's not hard-coded. >> >> Unfortunately, the first cipher suites using SHA256 are the one defined in >> TLS1.2 (RFC5246), and I believe the support for this RFC is still not >> included by NSS. >> >> It would not be a lot of work to implement at least >> TLS_RSA_WITH_AES_128_CBC_SHA256 , TLS_RSA_WITH_AES_256_CBC_SHA256 , >> TLS_DH_RSA_WITH_AES_128_CBC_SHA256 , TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as >> it would just mean replacing SHA1 with SHA256 wrt the equivalent SHA1 >> suites, but it has not been done yet. I think an external contributor could >> do it. > > Yes. Would you be interested in working on this? > I found an existing request for TLS 1.2 in Bugzilla: > https://bugzilla.mozilla.org/show_bug.cgi?id=480514 > > Wan-Teh I believe we must also support TLS 1.1 if we with to support TLS 1.2. I'd suggest that anyone wishing to make a major new contribution to NSS's SSL/TLS code start by working on TLS 1.1, then when they've accomplished that, they'll have learned what they need to do to accomplish TLS 1.2 (which will be MUCH more work than 1.1). -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
On Wed, Mar 3, 2010 at 4:05 AM, Jean-Marc Desperrier wrote: > > TLS depends on the cipher-suites, and fortunately it's not hard-coded. > > Unfortunately, the first cipher suites using SHA256 are the one defined in > TLS1.2 (RFC5246), and I believe the support for this RFC is still not > included by NSS. > > It would not be a lot of work to implement at least > TLS_RSA_WITH_AES_128_CBC_SHA256 , TLS_RSA_WITH_AES_256_CBC_SHA256 , > TLS_DH_RSA_WITH_AES_128_CBC_SHA256 , TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as > it would just mean replacing SHA1 with SHA256 wrt the equivalent SHA1 > suites, but it has not been done yet. I think an external contributor could > do it. Yes. Would you be interested in working on this? I found an existing request for TLS 1.2 in Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=480514 Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Gregory BELLIER wrote: Ok, so it's still sha1 by default for S/Mime ? Is it also sha1 by default for TLS ? TLS depends on the cipher-suites, and fortunately it's not hard-coded. Unfortunately, the first cipher suites using SHA256 are the one defined in TLS1.2 (RFC5246), and I believe the support for this RFC is still not included by NSS. It would not be a lot of work to implement at least TLS_RSA_WITH_AES_128_CBC_SHA256 , TLS_RSA_WITH_AES_256_CBC_SHA256 , TLS_DH_RSA_WITH_AES_128_CBC_SHA256 , TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as it would just mean replacing SHA1 with SHA256 wrt the equivalent SHA1 suites, but it has not been done yet. I think an external contributor could do it. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Konstantin Andreev a écrit :
On Wen, 03 Jun 2009, Nelson B Bolyard wrote:
Finally, I will add that (IINM) Thunderbird 3 has support for AES.
I don't know about the SHA1 vs SHA2 issue.
No, it hasn't, TB hardcodes SHA1. No variations:
( begin cite )
nsresult
nsMsgComposeSecure::MimeInitMultipartSigned()
{
...
/* Now initialize the crypto library, so that we can compute a hash
on the object which we are signing.
*/
mHashType = nsICryptoHash::SHA1;
PR_SetError(0,0);
mDataHash = do_CreateInstance("@mozilla.org/security/hash;1", &rv);
if (NS_FAILED(rv)) return 0;
rv = mDataHash->Init(mHashType);
...
( end cite )
[https://mxr.mozilla.org/comm-central/source/mailnews/extensions/smime/src/nsMsgComposeSecure.cpp#496]
On Thu, 04 Jun 2009, Nelson B Bolyard wrote:
On 2009-07-02 02:20 PDT, Jean-Marc Desperrier wrote:
I'm not very well placed to give a specification, but it seems it's
really nothing more than "take sMIMECapabilities, include it inside
x509".
It would be good to include the RFE also in Dogtag then.
I have subsequently learned that this is specified in RFC 4262.
I have filed RFEs for NSS and for Dogtag. I CC'ed you on the NSS RFE.
https://bugzilla.mozilla.org/show_bug.cgi?id=502139
This enhancement will be useless until Mozilla/"MailNews Core" attends
these capabilities. Given that TB security enhancements are stalled
for years, I wouldn't rely on this.
Ok, so it's still sha1 by default for S/Mime ?
Is it also sha1 by default for TLS ?
Regards,
Gregory.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
On 2009-12-25 08:28 PST, Konstantin Andreev wrote:
> On Wen, 03 Jun 2009, Nelson B Bolyard wrote:
>> Finally, I will add that (IINM) Thunderbird 3 has support for AES.
>> I don't know about the SHA1 vs SHA2 issue.
>
> No, it hasn't, TB hardcodes SHA1. No variations:
>
> ( begin cite )
> nsresult
> nsMsgComposeSecure::MimeInitMultipartSigned()
> {
>...
>/* Now initialize the crypto library, so that we can compute a hash
> on the object which we are signing.
> */
>mHashType = nsICryptoHash::SHA1;
>
>PR_SetError(0,0);
>mDataHash = do_CreateInstance("@mozilla.org/security/hash;1", &rv);
>if (NS_FAILED(rv)) return 0;
>
>rv = mDataHash->Init(mHashType);
>...
> ( end cite )
>
> [https://mxr.mozilla.org/comm-central/source/mailnews/extensions/smime/src/nsMsgComposeSecure.cpp#496]
OK, that code is outside of NSS. I was referring to the CMS library in NSS.
But as you have noted, if the caller of the CMS library specifies SHA1,
that is what it will get.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re[2]: S/MIME in Thunderbird
On Wen, 03 Jun 2009, Nelson B Bolyard wrote:
Finally, I will add that (IINM) Thunderbird 3 has support for AES.
I don't know about the SHA1 vs SHA2 issue.
No, it hasn't, TB hardcodes SHA1. No variations:
( begin cite )
nsresult
nsMsgComposeSecure::MimeInitMultipartSigned()
{
...
/* Now initialize the crypto library, so that we can compute a hash
on the object which we are signing.
*/
mHashType = nsICryptoHash::SHA1;
PR_SetError(0,0);
mDataHash = do_CreateInstance("@mozilla.org/security/hash;1", &rv);
if (NS_FAILED(rv)) return 0;
rv = mDataHash->Init(mHashType);
...
( end cite )
[https://mxr.mozilla.org/comm-central/source/mailnews/extensions/smime/src/nsMsgComposeSecure.cpp#496]
On Thu, 04 Jun 2009, Nelson B Bolyard wrote:
On 2009-07-02 02:20 PDT, Jean-Marc Desperrier wrote:
I'm not very well placed to give a specification, but it seems it's really nothing more
than "take sMIMECapabilities, include it inside x509".
It would be good to include the RFE also in Dogtag then.
I have subsequently learned that this is specified in RFC 4262.
I have filed RFEs for NSS and for Dogtag. I CC'ed you on the NSS RFE.
https://bugzilla.mozilla.org/show_bug.cgi?id=502139
This enhancement will be useless until Mozilla/"MailNews Core" attends these
capabilities. Given that TB security enhancements are stalled for years, I wouldn't rely
on this.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird (and why its assumptions are bogus)
2009/6/26 Michael Ströder : Nelson B Bolyard wrote: But only a small minority of mail users use MUAs that reside on their own computers today. Webmail rules, That might be true in the U.S. It's not true here in Germany. and entrusting your private key to your free webmail provider makes no sense at all. Yupp. Ergh. I'm about to go on another rant (one with policy implications, but more having to do with how MUAs and protecting private keys in the engineering side of things is related to extremely outdated thinking). Please don't take offense. In the Old Thinking[tm], keys were so expensive to create that they should be guarded like the lifeblood of one's very identity. In the New Thinking, why not create a temporary proxy certificate for a key created on your webmail provider? That way, it's easy to tell who did what, within what validity period. As long as The Subject's Private Key doesn't get into the hands of anyone, it can be used to do anything (as allowed by its keyUsage, anyway). It can be used to delegate powers of the Subject, in the same way that allowing a Power of Attorney or such can be used in the offline world. Keys are cheap. The processing power required to create a key is cheap. Why are we so insistent on not using more than A Single Point Of Failure, which is solely in the hands of the end-user to not muck up, as part of any of these protocols we discuss? -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Michael Ströder wrote: - add a time-stamp and update the S/MIME capabilities and timestamp whenever a new S/MIME message is received. - use the cert extension solely when no signed S/MIME message was received so far or the notBefore date of the e-mail cert is newer than the timestamp of the last S/MIME caps stored. I 100% agree with that, use a time-stamp, and when using the cert extension, set the time-stamp value to the issuance date. Still this assumes that the issuing CA really knows about the correct S/MIME caps which could be true for corporate CAs issuing e-mail certs for a well-defined set of MUAs. This would be a defect correction for RFC 4262, only use this extension in those condition, or if you have properly evaluated it's consequences. But the client can do no better than assume the cert issuer knew what it's doing. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Jean-Marc Desperrier wrote: > Nelson B Bolyard wrote: >>> Does this assume LDAP for acquiring the certificate without a signed >>> > S/MIME message? (So it is only relevant in corporate setting?) > >> No. There are many ways to get a cert for an email correspondent. >> There is only one way to get that correspondent's email capabilities in a >> form that Mozilla mail clients can understand, and that is to receive a >> signed email. > > For what it's worth, I've seen that the Microsoft Certificate Server > product includes a sMIMECapabilities attribute directly inside X509 mail > encryption certificates it issues. > > This non-standard usage could be interpreted as "I'll make sure any MUA > that I use with this certificate will support at least this level of > security". Hmm, thinking about this a bit more I have some comments: There is no such thing as a "level of security". AFAICS the sMIMECapabilities are just an unordered set of algorithm identifiers without any provisions about the security level of these ciphers. When a MUA sends sMIMECapabilities in a signed S/MIME message it sends a set of the ciphers *currently* supported by this particular MUA. This can change over time. A new signed S/MIME message should update the sMIMECapabilities for the sender's e-mail address in the receiver's MUA. So if the user changes a MUA he/she has control over updating the sMIMECapabilities in receiver's MUA. If the CA makes an assertion about sMIMECapabilities in this X.509v3 cert extension how is it supposed to be handled? Should the receiver's MUA take the intersection or the union of sMIMECapabilities cert extension and sMIMECapabilities in signed S/MIME message? Personally I'd vote for giving the sender's MUA predecence over what's stated in the e-mail cert but one could also argue the other way round. > Also, it can be said an encryption certificate without the info of what > encryption protocol the holder is ready to use is much less useful. Wouldn't a X.509v3 cert with extension sMIMECapabilities imply that this e-mail cert can be used with S/MIME? Ciao, Michael. -- Michael Ströder E-Mail: mich...@stroeder.com http://www.stroeder.com -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Nelson Bolyard wrote: > I wrote: >>> If Microsoft has merely taken a DER-encoded object from another standard >>> and has incorporated it into a cert extension, that seems fine to me. >>> I hope they did it in such a way that existing BER/DER parsers of the >>> sMIMECapabilities attribute can just parse the extension body directly. > [..] > I have subsequently learned that this is specified in RFC 4262. IMHO there are pros and cons for using this cert extension. I think section 3. and 4. of RFC 4262 are a bit vague about the implementation details and security considerations. I don't know how NSS caches the S/MIME capabilities received in signed S/MIME messages. But I'd suggest to add a time-stamp and update the S/MIME capabilities and timestamp whenever a new S/MIME message is received. I'd suggest to use the cert extension solely when no signed S/MIME message was received so far or the notBefore date of the e-mail cert is newer than the timestamp of the last S/MIME caps stored. Still this assumes that the issuing CA really knows about the correct S/MIME caps which could be true for corporate CAs issuing e-mail certs for a well-defined set of MUAs. Ciao, Michael. -- Michael Ströder E-Mail: mich...@stroeder.com http://www.stroeder.com -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
I wrote: >> If Microsoft has merely taken a DER-encoded object from another standard >> and has incorporated it into a cert extension, that seems fine to me. >> I hope they did it in such a way that existing BER/DER parsers of the >> sMIMECapabilities attribute can just parse the extension body directly. >> If you could supply a specification for this new extension, I'd file an >> RFE for Thunderbird/NSS to handle these certs in the intended manner. On 2009-07-02 02:20 PDT, Jean-Marc Desperrier wrote: > I'm not very well placed to give a specification, but it seems it's > really nothing more than "take sMIMECapabilities, include it inside x509". > > It would be good to include the RFE also in Dogtag then. I have subsequently learned that this is specified in RFC 4262. I have filed RFEs for NSS and for Dogtag. I CC'ed you on the NSS RFE. https://bugzilla.mozilla.org/show_bug.cgi?id=502139 https://bugzilla.redhat.com/show_bug.cgi?id=509481 Thank you for bringing this to my attention. /Nelson -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Nelson B Bolyard wrote:
If Microsoft has merely taken a DER-encoded object from another standard
and has incorporated it into a cert extension, that seems fine to me.
I hope they did it in such a way that existing BER/DER parsers of the
sMIMECapabilities attribute can just parse the extension body directly.
Openssl recognise it as sMIMECapabilities, but apparently does not
really include the layer to really interpret that extension.
Here is the content of the extension as it appears inside a certificate
I have :
MEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUr
DgMCBzAKBggqhkiG9w0DBw==
and the result dumpasn1 gives on it :
0 68: SEQUENCE {
29: OBJECT IDENTIFIER sMIMECapabilities (1 2 840 113549 1 9 15)
13 55: OCTET STRING, encapsulates {
15 53: SEQUENCE {
17 14: SEQUENCE {
198: OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
292: INTEGER 128
: }
33 14: SEQUENCE {
358: OBJECT IDENTIFIER rc4 (1 2 840 113549 3 4)
452: INTEGER 128
: }
497: SEQUENCE {
515: OBJECT IDENTIFIER desCBC (1 3 14 3 2 7)
: }
58 10: SEQUENCE {
608: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7)
: }
: }
: }
: }
I'll send you the cert in private mail. I've just checked the extension
appears only in mail encryption cert (KU=key exchange), not in mail
signature cert (KU=signature).
Also, testing MCS in any server edition of windows is nothing more than
going in Control Panel, selecting "Add/Remove Windows Component",
clicking "Certificate Services", and finding back the install CD/DVDs
(which might be more difficult). They are a few question you need to
answer, but it's really not difficult, you just need to select a "Stand
Alone" authority so that you don't need to integrate it with Active
Directory.
If you could supply a specification for this new extension, I'd file an
RFE for Thunderbird/NSS to handle these certs in the intended manner.
I'm not very well placed to give a specification, but it seems it's
really nothing more than "take sMIMECapabilities, include it inside x509".
It would be good to include the RFE also in Dogtag then.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
On 2009-06-30 07:39 PDT, Jean-Marc Desperrier wrote: > Nelson B Bolyard wrote: >>> Does this assume LDAP for acquiring the certificate without a signed S/MIME message? (So it is only relevant in corporate setting?) > >> No. There are many ways to get a cert for an email correspondent. >> There is only one way to get that correspondent's email capabilities in a >> form that Mozilla mail clients can understand, and that is to receive a >> signed email. > > For what it's worth, I've seen that the Microsoft Certificate Server > product includes a sMIMECapabilities attribute directly inside X509 mail > encryption certificates it issues. Do you have some example certs that I could examine? > This non-standard usage could be interpreted as "I'll make sure any MUA > that I use with this certificate will support at least this level of > security". That seems like a GREAT idea! (This is one of those "why didn't I think of that?" ideas.) > Whilst I don't usually support Microsoft in reinterpreting standards, in > that case I'll make an exception. I see the X.509v3 standard as being infinitely extensible in the area of certificate extensions. Anyone can get his own arc in the OID tree, and then define his own certificate extension using that OID. (You know about Peter Gutmann's certificate with an embedded JPG image of a cat, right? :) If Microsoft has merely taken a DER-encoded object from another standard and has incorporated it into a cert extension, that seems fine to me. I hope they did it in such a way that existing BER/DER parsers of the sMIMECapabilities attribute can just parse the extension body directly. If you could supply a specification for this new extension, I'd file an RFE for Thunderbird/NSS to handle these certs in the intended manner. > After all, even when you respect the standard and put sMIMECapabilities > only inside a SMIME message, nothing guaranties that you'll be using the > same MUA when you read the response. True, although, you probably want to minimize the number of different places that have access to your private key, so you're not likely to have MANY MUAs. But even two different MUAs with different capabilities in enough to make this an important consideration. > It's up to you to make sure that none of the MUA you use makes promises > another of them can't support, which is only a little less dangerous > than including them directly in the certificate. > > Also, it can be said an encryption certificate without the info of what > encryption protocol the holder is ready to use is much less useful. Yes. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Nelson B Bolyard wrote: Does this assume LDAP for acquiring the certificate without a signed > S/MIME message? (So it is only relevant in corporate setting?) No. There are many ways to get a cert for an email correspondent. There is only one way to get that correspondent's email capabilities in a form that Mozilla mail clients can understand, and that is to receive a signed email. For what it's worth, I've seen that the Microsoft Certificate Server product includes a sMIMECapabilities attribute directly inside X509 mail encryption certificates it issues. This non-standard usage could be interpreted as "I'll make sure any MUA that I use with this certificate will support at least this level of security". Whilst I don't usually support Microsoft in reinterpreting standards, in that case I'll make an exception. After all, even when you respect the standard and put sMIMECapabilities only inside a SMIME message, nothing guaranties that you'll be using the same MUA when you read the response. It's up to you to make sure that none of the MUA you use makes promises another of them can't support, which is only a little less dangerous than including them directly in the certificate. Also, it can be said an encryption certificate without the info of what encryption protocol the holder is ready to use is much less useful. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Google's Wave Was: S/MIME in Thunderbird
Ian G wrote: >> Google's Wave will hopefully be the finale for S/MIME. >Hmmm, tell me more. It does look interesting! >How is it secured? I read some blurbs and things but I'm hoping someone >knows the answers. I must confess that I don't have detailed knowledge about "Wave" but it appears to be based on Google Talk and is said to be a distributed IM+ system and more. I'm sure that there always well be a market for true end-to-end encryption but the drawbacks of using message encryption compared to session encryption derived from an authentication means that it will be almost non-measurable and thus is of no interest to me at least. In fact, TTP- based on-line message schemes can add really interesting qualities such as hiding the identities of their clients so that only the final recipient get that information. An interesting observation is that Google launched this in an early state as running code and as it appears, completely on their own. This is exactly what will also happen with the stuff I work with; standardization simply isn't going anywhere! I have participated in several stds. bodies that didn't get their act together :-( The biggest hurdle is that many people are unclear with what their true goals are which I think has been visible in the S/MIME debates Something that I almost always find lacking is a deployment strategy. Personally I think this is more important than the actual standard itself! Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
On 26/6/09 23:51, Anders Rundgren wrote: Google's Wave will hopefully be the finale for S/MIME. Hmmm, tell me more. It does look interesting! How is it secured? I read some blurbs and things but I'm hoping someone knows the answers. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Eddy Nigg wrote: >On 06/26/2009 09:18 PM, Michael Ströder: >>> But only a small minority of mail users use MUAs >>> that reside on their own computers today. Webmail rules, >> That might be true in the U.S. It's not true here in Germany. >Webmail doesn't rule...otherwise somebody explain to me from what MS >makes their revenues if not from Office, Exchange, Windows Mobile etc... Oh, the two "big-brains" are again out on a crusade to save S/MIME and fat e-mail clients. We other "idiots" who occasionally need to access our mail from computers we don't mange, happily continue using that evil thing known as web mail. Google's Wave will hopefully be the finale for S/MIME. Unlike for genius Michael Jackson, the mourning crowd will be small and almost cheerful :-) Your other protégé , I will put to rest with a little help from my friends :-) Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
On 06/26/2009 09:18 PM, Michael Ströder: Nelson B Bolyard wrote: But only a small minority of mail users use MUAs that reside on their own computers today. Webmail rules, That might be true in the U.S. It's not true here in Germany. Webmail doesn't rule...otherwise somebody explain to me from what MS makes their revenues if not from Office, Exchange, Windows Mobile etc... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Nelson B Bolyard wrote: > But only a small minority of mail users use MUAs > that reside on their own computers today. Webmail rules, That might be true in the U.S. It's not true here in Germany. > and entrusting your private key to your free webmail provider makes > no sense at all. Yupp. Ciao, Michael. -- Michael Ströder E-Mail: mich...@stroeder.com http://www.stroeder.com -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Anders Rundgren wrote: > Gervase Markham wrote: >>> The biggest impediment to secure email today is the existence and >>> popularity of webmail. In Mozilla terms, the biggest impediment to >>> Thunderbird today is Firefox. > >> It seems that people are happy to make the trade-off of privacy >> against convenience here. I suspect it's unlikely that we are going to >> be able to change their minds on that. Hence extensions like the above. > > IMHO Web-mail *adds* security to the e-mail ecosystem since it requires > the user to authenticate in order to send a message. Here in Germany most public e-mail providers also require you to authenticate when connecting via SMTP. You can also use SMTP with STARTTLS to protect the password transmitted. So this is no strong argument for webmail. > Encryption is another thing which is impossible to scale-up using an > off-line e-mail model. ??? When using Seamonkey as MUA I prepare S/MIME-encrypted/signed e-mail to project members saving the message to folder "Unsent Messages" for later delivery via SMTP. Oh my god, it works! Please tell what I'm doing wrong. ;-} > Exchanging certificates also violates the privacy > anyway since one of the most secret things is actually *who* you > communicate with. ??? Ciao, Michael. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
I really hate the licensing on that add-on, by the way -- it flies in the face of what freedom is, and they call it the "doubly-free" license by removing the freedom associated with the GPL? -Kyle H On Thu, Jun 25, 2009 at 2:31 AM, Gervase Markham wrote: On 24/06/09 23:49, Nelson B Bolyard wrote: S/MIME's protection of message authenticity, integrity and confidentiality are unbroken and unsurpassed. It is implemented in most Windows, Mac and Linux email MUA's today. But only a small minority of mail users use MUAs that reside on their own computers today. Webmail rules, and entrusting your private key to your free webmail provider makes no sense at all. https://addons.mozilla.org/en-US/firefox/addon/592 :-) The biggest impediment to secure email today is the existence and popularity of webmail. In Mozilla terms, the biggest impediment to Thunderbird today is Firefox. It seems that people are happy to make the trade-off of privacy against convenience here. I suspect it's unlikely that we are going to be able to change their minds on that. Hence extensions like the above. Do you remember what happened to MD5? Without crypto agility, the only solution would have been an "Internet flag day", on which the whole world obsoleted and replaced its old MD5 stuff with some newer hash. Crypto agility allowed a smooth effortless migration for all but a few stragglers. +1 for crypto agility. Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Gervase Markham wrote: The biggest impediment to secure email today is the existence and popularity of webmail. In Mozilla terms, the biggest impediment to Thunderbird today is Firefox. It seems that people are happy to make the trade-off of privacy against convenience here. I suspect it's unlikely that we are going to be able to change their minds on that. Hence extensions like the above. IMHO Web-mail *adds* security to the e-mail ecosystem since it requires the user to authenticate in order to send a message. In addition, few Web-mail systems allow you to send under any other e-mail address than that of the account. Encryption is another thing which is impossible to scale-up using an off-line e-mail model. Exchanging certificates also violates the privacy anyway since one of the most secret things is actually *who* you communicate with. You don't *have* to be a criminal to think so :-) Google's Wave is more likely to answer our prayers than secure e-mail. That means Firefox all the way. Browsers rock! Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
On 24/06/09 23:49, Nelson B Bolyard wrote: S/MIME's protection of message authenticity, integrity and confidentiality are unbroken and unsurpassed. It is implemented in most Windows, Mac and Linux email MUA's today. But only a small minority of mail users use MUAs that reside on their own computers today. Webmail rules, and entrusting your private key to your free webmail provider makes no sense at all. https://addons.mozilla.org/en-US/firefox/addon/592 :-) The biggest impediment to secure email today is the existence and popularity of webmail. In Mozilla terms, the biggest impediment to Thunderbird today is Firefox. It seems that people are happy to make the trade-off of privacy against convenience here. I suspect it's unlikely that we are going to be able to change their minds on that. Hence extensions like the above. Do you remember what happened to MD5? Without crypto agility, the only solution would have been an "Internet flag day", on which the whole world obsoleted and replaced its old MD5 stuff with some newer hash. Crypto agility allowed a smooth effortless migration for all but a few stragglers. +1 for crypto agility. Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
On 2009-06-21 03:24 PDT, Ian G wrote: > On 19/6/09 15:36, Jean-Marc Desperrier wrote: >> Nelson B Bolyard wrote: >>> if you send an encrypted message to someone from whom you have never >>> received a signed S/MIME message, you will use weak encryption. > > Does this assume LDAP for acquiring the certificate without a signed > S/MIME message? (So it is only relevant in corporate setting?) No. There are many ways to get a cert for an email correspondent. There is only one way to get that correspondent's email capabilities in a form that Mozilla mail clients can understand, and that is to receive a signed email. >> Thank you for this useful description. >> >> I feel it would make sense to open a bug to change this default. That would be bug 84213, 8 years old this month. >> Rational : If someone went the hassle of doing everything it requires >> to send an encrypted mail, he needs his message to be encrypted more >> than he needs it to be 100% compatible with everybody. I guess Jean-Marc was saying that it is more important that the message be encrypted than that the intended recipient can decrypt it. That's the issue here. The S/MIME standards (of 1999) defined a minimum set of crypto capabilities that must be implemented by any product that claims compliance with those standards. Those standards provide that, if you don't know the specific capabilities of your correspondent, then you send the message using only those minimum capabilities, because that way you are sure that your correspondent will be able to decrypt your message. If you send it using some optional set of capabilities, your recipient may not be able to decrypt it. Interoperability is the whole point. Actually, the 1999 standards defined two different sets of minimum capabilities, one of which was legally exportable from the US at that time, and one which was not. Since NSS and the S/MIME component of the Mozilla email client were being developed for use world-wide, we chose the legally exportable minimum set. Two years later, when the export rules had changed, we agreed that it should be changed, but by then, the S/MIME capabilities of Mozilla's mail client were already orphaned. > S/MIME is pretty much broken as a design. S/MIME's protection of message authenticity, integrity and confidentiality are unbroken and unsurpassed. It is implemented in most Windows, Mac and Linux email MUA's today. But only a small minority of mail users use MUAs that reside on their own computers today. Webmail rules, and entrusting your private key to your free webmail provider makes no sense at all. The biggest impediment to secure email today is the existence and popularity of webmail. In Mozilla terms, the biggest impediment to Thunderbird today is Firefox. > Old topic. The flaw that was introduced was two-fold. One was the old > ITAR crypto regulations (as Kyle mentioned), Agreed. That was probably the biggest road block and its effects persist today, long after it changed. > and the other was a sort of mad-scientist principle of "crypto agility" > which allowed people to be incompatible with each other and software to > be confusingly complicated. Do you remember what happened to MD5? Without crypto agility, the only solution would have been an "Internet flag day", on which the whole world obsoleted and replaced its old MD5 stuff with some newer hash. Crypto agility allowed a smooth effortless migration for all but a few stragglers. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Ian G wrote: > On 19/6/09 15:36, Jean-Marc Desperrier wrote: >> Nelson B Bolyard wrote: >>> if you send an encrypted message to >>> someone from whom you have never received a signed S/MIME message, you >>> will >>> use weak encryption. > > Does this assume LDAP for acquiring the certificate without a signed > S/MIME message? (So it is only relevant in corporate setting?) Or other situations where you solely have a S/MIME cert. > S/MIME is pretty much broken as a design. IMHO it is not worth fiddling > around at the edges, because you'll fix one little thing and won't > achieve a thing. 100 other little things will bring you down. Strange enough it's useful for some people. I'd simply like to have some more S/MIME-related settings in Thunderbird and Seamonkey in the config UI. And also both products should display the symmetric cipher and key strengths actually used in a S/MIME message like it's already done for SSL connections. Ciao, Michael. -- Michael Ströder E-Mail: mich...@stroeder.com http://www.stroeder.com -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
On 19/6/09 15:36, Jean-Marc Desperrier wrote: Nelson B Bolyard wrote: if you send an encrypted message to someone from whom you have never received a signed S/MIME message, you will use weak encryption. Does this assume LDAP for acquiring the certificate without a signed S/MIME message? (So it is only relevant in corporate setting?) Thank you for this useful description. I feel it would make sense to open a bug to change this default. Rational : If someone went the hassle of doing everything it requires to send an encrypted mail, he needs his message to be encrypted more than he needs it to be 100% compatible with everybody. S/MIME is pretty much broken as a design. IMHO it is not worth fiddling around at the edges, because you'll fix one little thing and won't achieve a thing. 100 other little things will bring you down. I think the big picture here is whether the Mozo Messaging people are ready to do some serious massaging. This is no easy question, because it will take quite some work up&down the stack, and it will likely upset many people because the spirit of PKI will have to be bent to serve the user, not the other way around. So it's not a popular project, who really cares enough about users to do all that work, and they will have to fight the gladiators of the last century over every feature. And today 40 bits security is so easy to break that nobody can seriously call that "encrypted". I take it very seriously :) If we had delivered even 40 bit security to the masses, I'd say we as an Internet community would have succeeded. We couldn't even do that. Old topic. The flaw that was introduced was two-fold. One was the old ITAR crypto regulations (as Kyle mentioned), and the other was a sort of mad-scientist principle of "crypto agility" which allowed people to be incompatible with each other and software to be confusingly complicated. To some extent (and maybe intended) this is the same flaw. Successful designs eliminate or bypass these bugs. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
No, it just means that Thunderbird needs to catch up with the times and implement a newer version of the specifications, one that was written after the US's draconian ITAR rules were changed. -Kyle H On Fri, Jun 19, 2009 at 6:48 AM, Georgi Guninski wrote: > On Fri, Jun 19, 2009 at 03:36:08PM +0200, Jean-Marc Desperrier wrote: >> Nelson B Bolyard wrote: >>> if you send an encrypted message to >>> someone from whom you have never received a signed S/MIME message, you will >>> use weak encryption. > > huh, is this an official statement? > > if this is true this means current CA roots are useless. > > > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
On Fri, Jun 19, 2009 at 03:36:08PM +0200, Jean-Marc Desperrier wrote: > Nelson B Bolyard wrote: >> if you send an encrypted message to >> someone from whom you have never received a signed S/MIME message, you will >> use weak encryption. huh, is this an official statement? if this is true this means current CA roots are useless. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
Nelson B Bolyard wrote: if you send an encrypted message to someone from whom you have never received a signed S/MIME message, you will use weak encryption. Thank you for this useful description. I feel it would make sense to open a bug to change this default. Rational : If someone went the hassle of doing everything it requires to send an encrypted mail, he needs his message to be encrypted more than he needs it to be 100% compatible with everybody. And today 40 bits security is so easy to break that nobody can seriously call that "encrypted". -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME in Thunderbird
On 2009-06-01 12:07 PDT, Andrew Manore wrote: > I'm not able to see what encryption algorithms Thunderbird 2.0.x is > using. From what I've been able to tell (through downloading the > encrypted message into Microsoft Outlook), Thunderbird is using 3DES > encryption with SHA-1 hashes. Thunderbird 2's S/MIME conforms to an old version of the specifications, RFC 2630 and RFC 2633, written in 1999, which was before the export control regulations were changed. As specified there, when you send a signed S/MIME message, it contains a record of your SMIME capabilities, the algorithms and key sizes that you support when you are RECEIVING S/MIME messages. A party who receives your signed message will know what algorithms you support and, when he sends you an enveloped message, he may use the strongest algorithms and key sizes that are mutually supported. However, if a party has only your certificate and not a signed message from you, he does not know your capabilities, and can only rely on your implementation implementing the minimum requirements for that version of S/MIME. The minimum requirements of that version were RC2 encryption with 40 bit keys. So, if you send an encrypted message to someone from whom you have never received a signed S/MIME message, you will use weak encryption. AFAIK, when you read an encrypted message, Thunderbird does not show you any information about the algorithms or key sizes used for the bulk data encryption. There are tools that can look at an encrypted message and tell you that information. They can do so even without having the certs or private keys of the recipient, because the information about the algorithms used is not encrypted. It is binary encoded however, so you need a tool to help decode it into a humanly readable form. Use if those tools is something a developer could do, but IMO, is not something that the average user could do. > I'm wondering if there's any way to change the encryption to AES (any > supported key length) and the hash to SHA-2. I'm also wondering if > there's a way to verify the form of encryption used. There doesn't seem > to be any option in the menus, nor any option in the advanced > configuration editor. AFAIK, there is no way for you to directly control the encryption algorithms used when you send an encrypted email. The algorithm is chosen automatically, as I explained above. Long ago, there were some preferences for choosing the ciphers that are sent out in your signed messages, which gave you some control over the ciphers that others use when sending encrypted messages to you. But those were removed long ago as part of an effort to "simplify" (read: dumb down) the security prefs. That was largely because EVERYONE assumed that the prefs controlled the encryption algorithms used when sending, not when receiving, and there was much angst among users over that. Finally, I will add that (IINM) Thunderbird 3 has support for AES. I don't know about the SHA1 vs SHA2 issue. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
S/MIME in Thunderbird
I'm not able to see what encryption algorithms Thunderbird 2.0.x is using. From what I've been able to tell (through downloading the encrypted message into Microsoft Outlook), Thunderbird is using 3DES encryption with SHA-1 hashes. I'm wondering if there's any way to change the encryption to AES (any supported key length) and the hash to SHA-2. I'm also wondering if there's a way to verify the form of encryption used. There doesn't seem to be any option in the menus, nor any option in the advanced configuration editor. Thanks! -- Andrew Manore -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
