608725 - Add GOST cryptoalgorithms to NSS and Thunderbird

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement)

Description

[Dmitry Avramenko]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5
Build Identifier: 

This is a patch set that enables the use of GOST cryptographic algorithms both in Firefox and Thunderbird.

S/MIME, CMS, TLS and PKCS#12 with GOST are implemented.

Cryptographic algorithms are used via recent addition to PKCS#11 standard, using the external token corresponding to that standard.
These patches are tested and created with this open source token: http://atoken.sourceforge.net/

Reproducible: Always

Comment 1

[Dmitry Avramenko]

Attachment: patch for mozilla-central trunk

Comment 2

[Dmitry Avramenko]

Attachment: patch for tests, to enable GOST in them

Comment 3

[Dmitry Avramenko]

Attachment: patch for comm-central trunk

Comment 4

[Wan-Teh Chang]

Comment on attachment 487330 [details] [diff] [review]
patch for mozilla-central trunk

I have some random comments after a quick look.

1. Please create a separate patch for the NSS changes (changes to files under the security/nss directory).  NSS is developed separately from Mozilla.  Changes to security/manager should be in the Mozilla patch.

2. If it's not too much trouble, please create a separate patch for changes to security/nss/lib/freebl, security/nss/lib/softoken, and security/nss/lib/cryptohi/sechash.c.  This subset is NSS is FIPS 140-2 validated, so we need to check in these changes first.  (security/nss/lib/cryptohi/sechash.c is outside the FIPS crypto module boundary, but it depends on your changes to security/nss/lib/freebl, so it should be part of this patch.)

3. Nit: rename HASH_GetHashOidTagByType to HASH_GetHashOidTagByHashType.

4. Lines longer than 80 characters should be folded.

5. Be careful with the comma (,) after the last item, like this:

>@@ -148,17 +148,18 @@ static smime_cipher_map_entry smime_ciph
> /*    cipher			algtag			parms		enabled  allowed */
> /*    ---------------------------------------------------------------------------------- */
>     { SMIME_RC2_CBC_40,		SEC_OID_RC2_CBC,	&param_int40,	PR_TRUE, PR_TRUE },
>     { SMIME_DES_CBC_56,		SEC_OID_DES_CBC,	NULL,		PR_TRUE, PR_TRUE },
>     { SMIME_RC2_CBC_64,		SEC_OID_RC2_CBC,	&param_int64,	PR_TRUE, PR_TRUE },
>     { SMIME_RC2_CBC_128,	SEC_OID_RC2_CBC,	&param_int128,	PR_TRUE, PR_TRUE },
>     { SMIME_DES_EDE3_168,	SEC_OID_DES_EDE3_CBC,	NULL,		PR_TRUE, PR_TRUE },
>     { SMIME_AES_CBC_128,	SEC_OID_AES_128_CBC,	NULL,		PR_TRUE, PR_TRUE },
>-    { SMIME_FORTEZZA,		SEC_OID_FORTEZZA_SKIPJACK, NULL,	PR_TRUE, PR_TRUE }
>+    { SMIME_FORTEZZA,		SEC_OID_FORTEZZA_SKIPJACK, NULL,	PR_TRUE, PR_TRUE },
>+    { SMIME_GOST,			SEC_OID_GOST28147,	NULL,		PR_TRUE, PR_TRUE },
> };

A compiler that we used before did not allow such commas.  I suggest that if the original code doesn't have a comma after the last item, don't add it.

6. You modified security/nss/lib/ssl.  I seem to recall GOST TLS cipher suites require TLS 1.2.  Does that mean you also implemented TLS 1.2?

>+    TLS_GOSTR341001_WITH_28147_CNT_IMIT,

Comment 5

[Dmitry Avramenko]

Attachment: patch for thunderbird comm-central trunk

Comment 6

[Dmitry Avramenko]

Attachment: patch for non-NSS sources in mozilla-central trunk

Comment 7

[Dmitry Avramenko]

Attachment: patch for NSS sources

Comment 8

[Dmitry Avramenko]

Attachment: patch for NSS tests (security/nss/cmd)

Comment 9

[Dmitry Avramenko]

Attachment: separate patch with freebl, softoken and sechash.c changes

Comment 10

[Dmitry Avramenko]

> 1. Please create a separate patch for the NSS changes (changes to files under
> the security/nss directory).  NSS is developed separately from Mozilla. 
> Changes to security/manager should be in the Mozilla patch.

Done.

> 2. If it's not too much trouble, please create a separate patch for changes to
> security/nss/lib/freebl, security/nss/lib/softoken, and
> security/nss/lib/cryptohi/sechash.c.  This subset is NSS is FIPS 140-2
> validated, so we need to check in these changes first. 
> (security/nss/lib/cryptohi/sechash.c is outside the FIPS crypto module
> boundary, but it depends on your changes to security/nss/lib/freebl, so it
> should be part of this patch.)

Done.

> 3. Nit: rename HASH_GetHashOidTagByType to HASH_GetHashOidTagByHashType.

Done.

> 4. Lines longer than 80 characters should be folded.

Done.

> 5. Be careful with the comma (,) after the last item, like this:
> 
> >@@ -148,17 +148,18 @@ static smime_cipher_map_entry smime_ciph
> > /*    cipher			algtag			parms		enabled  allowed */
> > /*    ---------------------------------------------------------------------------------- */
> >     { SMIME_RC2_CBC_40,		SEC_OID_RC2_CBC,	&param_int40,	PR_TRUE, PR_TRUE },
> >     { SMIME_DES_CBC_56,		SEC_OID_DES_CBC,	NULL,		PR_TRUE, PR_TRUE },
> >     { SMIME_RC2_CBC_64,		SEC_OID_RC2_CBC,	&param_int64,	PR_TRUE, PR_TRUE },
> >     { SMIME_RC2_CBC_128,	SEC_OID_RC2_CBC,	&param_int128,	PR_TRUE, PR_TRUE },
> >     { SMIME_DES_EDE3_168,	SEC_OID_DES_EDE3_CBC,	NULL,		PR_TRUE, PR_TRUE },
> >     { SMIME_AES_CBC_128,	SEC_OID_AES_128_CBC,	NULL,		PR_TRUE, PR_TRUE },
> >-    { SMIME_FORTEZZA,		SEC_OID_FORTEZZA_SKIPJACK, NULL,	PR_TRUE, PR_TRUE }
> >+    { SMIME_FORTEZZA,		SEC_OID_FORTEZZA_SKIPJACK, NULL,	PR_TRUE, PR_TRUE },
> >+    { SMIME_GOST,			SEC_OID_GOST28147,	NULL,		PR_TRUE, PR_TRUE },
> > };
> 
> A compiler that we used before did not allow such commas.  I suggest that if
> the original code doesn't have a comma after the last item, don't add it.

Fixed just as you said, in places where the original code doesnt have a comma. Or should I fix it everywhere?

> 6. You modified security/nss/lib/ssl.  I seem to recall GOST TLS cipher suites
> require TLS 1.2.  Does that mean you also implemented TLS 1.2?
> 
> >+    TLS_GOSTR341001_WITH_28147_CNT_IMIT,

This cipher suite is described in an outdated RFC proposal draft for TLS 1.2, but, in fact, it is widely implemented under TLS 1.0 version. Also, de facto, its implied that this cipher suite should be implemented in the same way for all existing TLS versions. I havent seen any working TLS 1.2 implementation with GOST cipher suites, all of them use TLS 1.0 (including openssl).

Comment 11

[Wan-Teh Chang]

Dmitry: thank you for the answers and new patches.  Regarding the comma,
it's not necessary to fix it everywhere.

Comment 12

[Alexander L. Slovesnik]

I've tried to compile Firefox with these patches applied (on Ubuntu 10.10 x32) and compilation failed with error:

gcc -o /home/unghost/mozilla_2.0/firefox_build/nss/pk11wrap/pk11slot.o -c -Os -gdwarf-2 -ansi -D_POSIX_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE -fPIC -Di386 -DLINUX2_1  -Wall -Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" -UDEBUG -DNDEBUG -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -I/home/unghost/mozilla_2.0/firefox_build/dist/include/nspr -I/home/unghost/mozilla_2.0/firefox_build/dist/include/nspr -I/home/unghost/mozilla_2.0/firefox_build/dist/public/nss -I/home/unghost/mozilla_2.0/firefox_build/dist/private/nss -I/home/unghost/mozilla_2.0/firefox_build/dist/public/dbm  pk11slot.c
pk11slot.c:84: error: ‘SECMOD_GOST_FLAG’ undeclared here (not in a function)
make[6]: *** [/home/unghost/mozilla_2.0/firefox_build/nss/pk11wrap/pk11slot.o] Ошибка 1
make[6]: Выход из каталога `/home/unghost/mozilla_2.0/mozilla-central/security/nss/lib/pk11wrap'
make[5]: *** [libs] Ошибка 2
make[5]: Выход из каталога `/home/unghost/mozilla_2.0/mozilla-central/security/nss/lib'
make[4]: *** [libs] Ошибка 2
make[4]: Выход из каталога `/home/unghost/mozilla_2.0/firefox_build/security/manager'
make[3]: *** [libs_tier_platform] Ошибка 2
make[3]: Выход из каталога `/home/unghost/mozilla_2.0/firefox_build'
make[2]: *** [tier_platform] Ошибка 2
make[2]: Выход из каталога `/home/unghost/mozilla_2.0/firefox_build'
make[1]: *** [default] Ошибка 2
make[1]: Выход из каталога `/home/unghost/mozilla_2.0/firefox_build'
make: *** [build] Ошибка 2

Comment 13

[Dmitry Avramenko]

> pk11slot.c:84: error: ‘SECMOD_GOST_FLAG’ undeclared here (not in a function)

SECMOD_GOST_FLAG is defined in security/nss/lib/softoken/secmodt.h patched by this https://bugzilla.mozilla.org/attachment.cgi?id=488213 patch. And secmodt.h is included in pk11slot.c.

Are you sure you have applied that separate patch for freebl/softoken/sechash.c?

Comment 14

[Alexander L. Slovesnik]

(In reply to comment #13)
> > pk11slot.c:84: error: ‘SECMOD_GOST_FLAG’ undeclared here (not in a function)
> 
> SECMOD_GOST_FLAG is defined in security/nss/lib/softoken/secmodt.h patched by
> this https://bugzilla.mozilla.org/attachment.cgi?id=488213 patch. And secmodt.h
> is included in pk11slot.c.
> 
> Are you sure you have applied that separate patch for
> freebl/softoken/sechash.c?
Oh, so overall "patch for NSS sources" doesn't include "separate patch with freebl, softoken and sechash.c changes". My fault, sorry.
Thanks for info.

Comment 15

[Dmitry Avramenko]

> Oh, so overall "patch for NSS sources" doesn't include "separate patch with
> freebl, softoken and sechash.c changes".
Yes, I've made these patches not overlapping.

Comment 16

[Dmitry Avramenko]

Attachment: patch for NSS sources

Some changes to make the patch more compliant with existing GOST TLS implementations.

Comment 17

[Nikolay Shopik]

Hi Dmitry,
take a look for bug 518787 and bug 519432, Konstantin Andreev had some drafts in last year and he told me in private email now reworking GOST patch to push it for review too ;).
You should request review for you patch, take look into super-review policy here http://www.mozilla.org/hacking/reviewers.html this fits into security I assume.

Comment 18

[Dmitry Avramenko]

(In reply to comment #17)
> Hi Dmitry,
Hello!

> take a look for bug 518787 and bug 519432, Konstantin Andreev had some drafts
> in last year and he told me in private email now reworking GOST patch to push
> it for review too ;).
Yes, I've seen them. And yes, I know who is Konstantin Andreev. And it's no surprise that he's telling about how he'll be doing something before actually doing it.
In any case, if he commits his patch that works, well, it's up to Mozilla team to choose which implementation to take.

> You should request review for you patch, take look into super-review policy
> here http://www.mozilla.org/hacking/reviewers.html this fits into security I
> assume.
Thanks, but I dont see such an option possible for this bug.

Comment 19

[Nikolay Shopik]

Correct list of NSS hackers is https://wiki.mozilla.org/Modules/Core#security here, thanks Alexander for correcting me.
(In reply to comment #18)

> Thanks, but I dont see such an option possible for this bug.
What option?

Comment 20

[Dmitry Avramenko]

(In reply to comment #19)
> > Thanks, but I dont see such an option possible for this bug.
> What option?
Didn't find how to set flags on patches at first, sorry.

Comment 21

[Dmitry Avramenko]

Attachment: patch for NSS sources

Update

Comment 22

[Andrey Gavrilin]

Attachment: gost cryptoalgorithms

I did it four years ago. The project was closed. Today I found the patch on my disk. It uses openssl. Sometimes it crashes because it has two memory allocators.

Comment 23

[Max]

Anything gonna happen with this bug? Do you need some help or is there something that blocks these patches?

I beg you to do something with this enhancement, because using of GOST cryptography is getting more and more required in Russia. Today there are some things which can be done ONLY using GOST encryption. I mean there is no more classical way for some things to be done, when you bring to the institution paper documents signed by you. Only in digital docs using GOST digital signature.

Regarding certification of GOST implementation in FSS - forget it! They do not certify only sources, they certify sources and compiled binaries so that a certificate contains hash sums of you binaries. This is dummy because after that you cannot even update your binaries with security hotfixes ) But this is Russia )

From the other side there is no strict requirement to use only certified version for simple people. It's a major problem only for various institution. Simply because nobody can check which implementation you are using for personal use. Of course at your own risk which contains possibilities of disclosure of your keys (bugs or an "enemy" backdoors) or incompatibilities with the certified implementations. But open source is open source: you can always check for backdoor, you can always fix bugs, you can always fix incompatibilities with other implementation.

So everyone gonna win if this will be included in the main brunch. Just as RedHat has sponsored FIPS certification, there will be russian distromakers which will sponsor certification of GOST in their distros if they need it. Ordinary users could just use it.

Comment 24

[Kai Engert (:KaiE:)]

I don't know if there will be progress on this bug.

Out of curiosity, are there any TLS servers on the public Internet that support GOST cipher suites, only?

Comment 25

[Kai Engert (:KaiE:)]

Can you point us to any documents (RFCs?) that specify how to use GOST with SSL/TLS?

Comment 26

[Max]

(In reply to Kai Engert (:kaie) from comment #24)
> Out of curiosity, are there any TLS servers on the public Internet that
> support GOST cipher suites, only?

Sure there are. E.g. a server of russian Federal Tax Service. https://lk3.nalog.ru

Comment 27

[Max]

(In reply to Kai Engert (:kaie) from comment #25)
> Can you point us to any documents (RFCs?) that specify how to use GOST with
> SSL/TLS?

AFAIK, there is only IETF Draft https://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04

But other uses of GOST ciphersuite has RFS's:
http://www.rfc-editor.org/info/rfc5933
http://www.rfc-editor.org/info/rfc4491
http://www.rfc-editor.org/info/rfc4490

Comment 28

[Eric Rescorla (:ekr)]

To the best of my knowledge, the TLS WG has never standardized GOST or assigned code points.

Comment 29

[Andrey Novikov]

Currently there are many services available only by TLS with GOST algorithms. Mostly this is an API endpoints (due to lack of support in browsers). For example this is https://service.rosminzdrav.ru/ (Federal Registry of Medicine Personnel). If anyone ever get need to integrate with any Russian government service it will find that there are only GOST crypto everywhere: TLS, SOAP digital signatures, etc. RSA either disallowed or deprecated.

On server-side world, OpenSSL have support for first generation of GOST algorithms since 1.0.0, and there is a patch for new ones at https://github.com/openssl/openssl/pull/75 (sadly there are no activity too).

So it's quite easy to get up Nginx running with GOST-only TLS.
For some programming languages there are patches and articles available to get them work with cryptography (TLS, encryption and digital signatures for files). 

For example for Ruby there are patches https://bugs.ruby-lang.org/issues/9822 and https://bugs.ruby-lang.org/issues/9830 and article http://habrahabr.ru/post/231261/ (in Russian)
For PHP there is article http://habrahabr.ru/post/189352/ (in Russian)

In front-end world situation is much worser: no support. There are some forks of browsers available, for example CryptoPro Fox by CryptoPro can be downloaded here: https://www.cryptopro.ru/products/cpfox , but it works only with installed CryptoPro CSP (it's paid and not user friendly at all). For example you can try to visit my test page at https://ssl-gost.envek.name/ (I've created it specially as test server for Ruby patches mentioned above, it's just Nginx and OpenSSL), CryptoProFox should open it.

Currently many Russian government services uses usual RSA based TLS for web UI, but under hood everything is GOST based. Also there are initiatives like UECard (universal electronic card: eID, e-ticket, and banking card), that is based on GOST algorithms only. I have one but can not sign emails because it's only works on Windows with proprietary soft installed.

And last: there is a lot more RFCs on GOST crypto (not only directly related to TLS):

RFC 4357: Additional Cryptographic Algorithms for Use with GOST Algorithms https://tools.ietf.org/html/rfc4357
RFC 4490: Using the GOST Algorithms with Cryptographic Message Syntax (CMS): https://tools.ietf.org/html/rfc4490
RFC 4491: Using the GOST Algorithms with the Internet X.509 Public Key Infrastructure: https://tools.ietf.org/html/rfc4491
RFC 5830: GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms: https://tools.ietf.org/html/rfc5830
RFC 5831: GOST R 34.11-94: Hash Function Algorithm: https://tools.ietf.org/html/rfc5831 (updated by RFC 6896)
RFC 5832: GOST R 34.10-2001: Digital Signature Algorithm: https://tools.ietf.org/html/rfc5832 (updated by RFC 7091)
RFC 6896: GOST R 34.11-2012: Hash Function: https://tools.ietf.org/html/rfc6986
RFC 7091: GOST R 34.10-2012: Digital Signature Algorithm: https://tools.ietf.org/html/rfc7091

Many other RFCs have information regarding GOST: 3279, 4055, 4491, 5480, 5758, 5933 and others.

My conslusion: There is already requirement for GOST crypto support, please, include it.

Comment 30

[Ryan Sleevi]

Speaking from the Chrome side, there is zero desire to support GOST. As ekr notes in Comment 28, the work is not standardized, and frankly, would be unlikely to, given the security concerns with the algorithms.

This creates an understandable tension between governments that may wish to require national crypto schemes (Fortezza/Skipjack, SEED, Camellia, GOST) and those parties entrusted to secure online communications (e.g. browsers). In general, governments regulating such schemes invariably and consistently harms Internet security, not helps.

Of these RFCs, the _only_ one relevant to the Web and that is _not_ an independent submission, informational-track document is RFC 4491, and coming from the PKIX WG, it may as well have been an independent, informational-track document.

There have been repeated discussions in the IRTF CFRG group discussing GOST in relation to Internet standards, and this is a widely held position from leading cryptographers and practioners.

The standard that I hope NSS follows, and that Chrome intentionally follows with BoringSSL, is to evaluate the merits of the algorithms proposed, not simply where it is required. It is the same as if Chrome was asked to support the gopher protocol because some nation required that all tax services be filed over Gopher.

Comment 31

[Nikolay Shopik]

> Also there are initiatives like UECard (universal electronic card: eID, e-ticket, and banking card), that is based on GOST algorithms only.

UECard aren't GOST only. Its required to support 3DES, RSA, SHA1.

Look for part 4.1.6 and 4.4.4 in spec

http://www.uecard.ru/upload/files/pdf/ps-uek/pravila-fuo/2-1/%D0%9E%D0%94-10_%D0%A1%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_%D0%A3%D0%AD%D0%9A_2.1.pdf

Comment 32

[Max]

(In reply to Nikolay Shopik from comment #31)
> > Also there are initiatives like UECard (universal electronic card: eID, e-ticket, and banking card), that is based on GOST algorithms only.
> 
> UECard aren't GOST only. Its required to support 3DES, RSA, SHA1.

Do you know anyone who has UECard with a RSA key pair and (optional) an appropriate certificate written on it?

Comment 33

[Max]

(In reply to Ryan Sleevi from comment #30)
> given the security concerns with the algorithms.

According to the Wikipedia, there is no known attack for GOST which makes it worse than AES.

> This creates an understandable tension between governments that may wish to
> require national crypto schemes (Fortezza/Skipjack, SEED, Camellia, GOST)
> and those parties entrusted to secure online communications (e.g. browsers).

Why it is bad? As we known competition is good. That is why there are Boeing and Airbus. USA visited the Moon when USSR was their opponent. Since USSR no longer exists, for the moment USA can't even bring their astronauts to the NSS ))

> In general, governments regulating such schemes invariably and consistently
> harms Internet security, not helps.

Who do you (I mean Google as you are speaking not your personal but from Chrome side) protect when you say about Internet security? Security is about protection, right?

We all remember the recent case with China CA and a valid fake certificate for Google inc. Even Google do not trust to the parties whose root certificates you include into the Chrome distro. Otherwise why Chrome checks for fingerprints of Google's certificate?

So, why governments of extraNA countries should trust to the existing cryptography infrastructure? Both including CAs and algorithms? It is their right to protect themselves.

Anyway you bring a lot of politics to the opensource project with such statements. I don't want to discuss here politics.

> The standard that I hope NSS follows, and that Chrome intentionally follows
> with BoringSSL, is to evaluate the merits of the algorithms proposed, not
> simply where it is required. It is the same as if Chrome was asked to
> support the gopher protocol because some nation required that all tax
> services be filed over Gopher.

Well, Gopher is not about security, right?

What about standards.... hm.. SPDY was not a standard when you added its support to the Chrome. Are you talking about "double standards" on the Chrome kitchen here? )

Comment 34

[Ryan Sleevi]

(In reply to Max from comment #33)
> According to the Wikipedia, there is no known attack for GOST which makes it
> worse than AES.

And with a few clicks, I can make ROT-13 more secure than AES, according to Wikipedia.

I already addressed why it doesn't meet our security bar.

> So, why governments of extraNA countries should trust to the existing
> cryptography infrastructure? Both including CAs and algorithms? It is their
> right to protect themselves.

You can do anything you want, you can regulate anything you want, you can dictate anything you want. That doesn't mean others must adopt your policies.

> Anyway you bring a lot of politics to the opensource project with such
> statements. I don't want to discuss here politics.

I did not bring politics into it. I again emphasized that this is a _technical_ valuation, and that the politics - such as Russia requiring it - does not change the _technical_ calculus.

Ciphersuites are not Pokemon. You don't need to catch them all / support them all. We make value judgments on technical merit as to what represents a sound, interoperable, secure set of ciphers. GOST is not one of those.

> What about standards.... hm.. SPDY was not a standard when you added its
> support to the Chrome. Are you talking about "double standards" on the
> Chrome kitchen here? )

I'm sorry, but despite the attempt to troll, you've missed my point. Just because something is legislatively required doesn't make it a good idea. Please re-read what I wrote again.

Regardless, I won't be commenting further, other than to note that GOST doesn't meet our bar for standardization OR security, lacks wide peer review and agreement on the security principals, and is of limited value and disproportionate risk.

Comment 35

[Max]

(In reply to Ryan Sleevi from comment #34)
> And with a few clicks, I can make ROT-13 more secure than AES, according to
> Wikipedia.
> 
> I already addressed why it doesn't meet our security bar.

Ok. You said about some mysterious security concerns about GOST ciphersuite. Would you provide any references so all parties of this discussion can judge themselves?

> You can do anything you want, you can regulate anything you want, you can
> dictate anything you want.

Wow-wow-wow. Calm down. I'm not going to regulate anyone or dictate anything. Frankly speaking I hate our regime. But your aggressive manner points me more and more that you are about politics.

> That doesn't mean others must adopt your policies.

Why inclusion support of GOST ciphersuite means that anyone would adopt someone's policy? Just do not use it if do not want to.

> I did not bring politics into it. I again emphasized that this is a
> _technical_ valuation, and that the politics - such as Russia requiring it -
> does not change the _technical_ calculus.

But you didn't provide any of you calculus.

> Ciphersuites are not Pokemon.

Agreed.

> You don't need to catch them all / support them all.

Well, I'm not about catching Pokenmons, but support for these algos is not your need. You are right. It is need of russian citizens. And no one is asking you to make all of the work. People above suggested pretty much finished work.

> We make value judgments on technical merit as to what represents a
> sound, interoperable, secure set of ciphers. GOST is not one of those.

Again, any evidences would be welcome. I admit that somebody hides from Russians that we all gonna be compromised.

> I'm sorry, but despite the attempt to troll, you've missed my point.

It wasn't a troll attempt. It was a attempt to show that your analogy with Gopher was incorrect based on your own actions.

> Just
> because something is legislatively required doesn't make it a good idea.
> Please re-read what I wrote again.

Agreed. But vice versa is correct too. Something that is legislatively required doesn't make it a bad idea.

Another fact is that a lot of bad ideas which are legislatively required were adopted by Google. I'm talking about your cooperation with security services of countries whose regimes are commonly considered as evil. Including Russian one.

And the third fact: if tomorrow Russian governors decide to block GMail until it supports GOST, we all will see such a support. And your will be the first here, who will promote it. Your luck that they are pretty dumb for this ) For a while )

Comment 36

[Max]

To summarize the discussion here, I provide the following thoughts.

1) There is already support for GOST from side vendors. It is not free. It's mainly supported on Windows.
1a) There is a demand for it.
2) It's supported with the use of various non-free plugins. (except the Chrome which dropped NPAPI).
3) It's supported with endless and not-legally-correct forked versions of common software such as Firefox and so on.
4) Support for it is pretty much ugly.
5) Ignoring it's support in NSS wouldn't make anyone happy. In fact it will just make unhappy about 5-10% of russian users who prefer free software instead of proprietary and a lot more of them who prefer free browsers and mail clients running on Microsoft's platform.
6) There are some standardization concerns but hey! C++ compilers begin to support new "standards" long before they got such status. Google and FF put some new protocols into browser long before they got a standard status (SPDY which became HTTP 2.0, Websockets and so on). Someone just has to be pioneer. Standardization leans on implementations. We all know standards which were designed before they were implemented: the OSI/ISO network stack is good thing to mention.

In Russia we have a proverb: if you can't cancel something you'd be better to be the head of it.

Comment 37

[Eddy Nigg (StartCom)]

Nowhere was an algorithm or hash associated with any country and neither should this. Otherwise we should start to label anything that comes out of NIST "US" or "American".

Comment 38

[Robert Relyea]

So I'm a little confused by the title of the bug. It asks to add Gost to NSS and Thunderbird. The discussion, though, revolves around SSL and the browser.

As an NSS developer, I'm only interested in adding those algorithms my immediate customers (such as Firefox and Thunderbird) want add. I've only heard scepticism from Mozilla folks, so I'm not really inclined to pick it up into NSS. Even if I did, there is no way to use them if the Firefox team doesn't want to turn it on in the browser.

There are a proliferation of good crypto standards out there, but it's not always a good idea to increase your attack surface on all of your customers to meet specialized needs. We are no longer advancing Seed and Camillo. Neither have GSM implementations yet. We don't support RC-6 or TwoFish. Back in the day (when idea was popular) we didn't support Idea. We've never supported Cast. Even Skipjack (the only US government generated standard) was barely support (we didn't have native support, you still required a PKCS #11 plugin).

All that being said, I would be OK with beefing up the NSS infrastructure to support better plugin crypto support. Thunderbird would take very little work to get there. SSL would take more. Even then you'd still need to coordinate somewhat with the browser (I suspect Firefox would want to explicitly turn off plugged in crypto by default just to reduce the attack surface).

bob

Comment 39

[Max]

Hi, Bob!

Thanks for your reply.

(In reply to Robert Relyea from comment #38)
> So I'm a little confused by the title of the bug. It asks to add Gost to NSS
> and Thunderbird. The discussion, though, revolves around SSL and the browser.

Well, I'm not sure why discussion went this way. Clearly that the topic is not about SSL, though support of GOST in SSL would be nice because the need of it increased since this bug was filed.

> As an NSS developer, I'm only interested in adding those algorithms my
> immediate customers (such as Firefox and Thunderbird) want add. I've only
> heard scepticism from Mozilla folks, so I'm not really inclined to pick it
> up into NSS. Even if I did, there is no way to use them if the Firefox team
> doesn't want to turn it on in the browser.

Well, I'm not sure who is who in this discussion, I only understand that Ryan Sleevi represents Chrome/Chromium project. And he has perfectly expressed his scepticism. What about Mozilla folks - I haven't seen their scepticism, may be in another discussion?

> All that being said, I would be OK with beefing up the NSS infrastructure to
> support better plugin crypto support. Thunderbird would take very little
> work to get there. SSL would take more.

I've read many discussions about GOST ciphersuite in various open-source project and participants always ask: if GOST is so cool, why Microsoft doesn't develop its own implementation? I suppose that the answer is pretty much as yours - the attack surface, except that they have left an ability to provide virtually any other ciphersuite seamless for users. And that's the key point of the discussion, I think. In the end, Russians just need the seamless GOST support. Will it be included in NSS and/or other software - it's not the question.

> Even then you'd still need to
> coordinate somewhat with the browser (I suspect Firefox would want to
> explicitly turn off plugged in crypto by default just to reduce the attack
> surface).

I hope there would be no counteraction from browser developers about adding such a new setting.

Comment 40

[Ryan Sleevi]

(In reply to Max from comment #39)
> (In reply to Robert Relyea from comment #38)
> > All that being said, I would be OK with beefing up the NSS infrastructure to
> > support better plugin crypto support. Thunderbird would take very little
> > work to get there. SSL would take more.
> 
> I've read many discussions about GOST ciphersuite in various open-source
> project and participants always ask: if GOST is so cool, why Microsoft
> doesn't develop its own implementation? I suppose that the answer is pretty
> much as yours - the attack surface, except that they have left an ability to
> provide virtually any other ciphersuite seamless for users. And that's the
> key point of the discussion, I think. In the end, Russians just need the
> seamless GOST support. Will it be included in NSS and/or other software -
> it's not the question.

Except NSS already supports pluggable cryptography (via PKCS #11), and can generally transparently pass that through to a module, provided it's a valid PKCS #11 operation. Some of the "high level" APIs for dealing with it don't work, but this is also (generally) true for Microsoft APIs and implementations, and somewhat of an intrinsic nature of PKCS #11.

Have you tried implementing your own PKCS #11 module that implements the appropriate GOST mechanisms (e.g. as described by http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/cos01/pkcs11-curr-v2.40-cos01.pdf )? That's the way to do pluggable crypto in the NSS world - there's no need to add support to softoken to have an _implementation_ of GOST itself.

If there are generally frictionless ways to expose the higher-level APIs (PK11_Encrypt and friends, I suppose; or SGN_* / VFY_*), then that can be evaluated on a case-by-case basis but w/o requiring the GOST implementation in NSS.

Comment 41

[Max]

(In reply to Ryan Sleevi from comment #40)
> Except NSS already supports pluggable cryptography (via PKCS #11), and can
> generally transparently pass that through to a module, provided it's a valid
> PKCS #11 operation. Some of the "high level" APIs for dealing with it don't
> work, but this is also (generally) true for Microsoft APIs and
> implementations, and somewhat of an intrinsic nature of PKCS #11.

Please, correct me if I'm wrong, but PKSC#11 is not enough to support TLS, since it doesn't contain any of TLS specific things. Microsoft CSP seems to be enough though to implement TLS without patching existing software. So these two things are not equal, the later seems to be more generic.

> Have you tried implementing your own PKCS #11 module that implements the
> appropriate GOST mechanisms (e.g. as described by
> http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/cos01/pkcs11-curr-v2.40-
> cos01.pdf )? That's the way to do pluggable crypto in the NSS world -
> there's no need to add support to softoken to have an _implementation_ of
> GOST itself.

No, I haven't. But this specification (actually this one http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf) is already outdated though it was standardized only a week ago: it has nothing about GOST 34.10-2012 and GOST 34.11-2012 which are replacements for 34.10-2001 and 34.11-94. But sure, I think that could be a good starting point.

Anyway, do you have any idea why the previous authors who implemented patches for NSS (AFAIK, there was at least two attempts) didn't follow this way? Is it something new, which wasn't supported at that time?

Comment 42

[Eric Rescorla (:ekr)]

(In reply to Max from comment #39)
> Hi, Bob!
> 
> Thanks for your reply.
> 
> (In reply to Robert Relyea from comment #38)
> > So I'm a little confused by the title of the bug. It asks to add Gost to NSS
> > and Thunderbird. The discussion, though, revolves around SSL and the browser.
> 
> Well, I'm not sure why discussion went this way. Clearly that the topic is
> not about SSL, though support of GOST in SSL would be nice because the need
> of it increased since this bug was filed.
> 
> > As an NSS developer, I'm only interested in adding those algorithms my
> > immediate customers (such as Firefox and Thunderbird) want add. I've only
> > heard scepticism from Mozilla folks, so I'm not really inclined to pick it
> > up into NSS. Even if I did, there is no way to use them if the Firefox team
> > doesn't want to turn it on in the browser.
> 
> Well, I'm not sure who is who in this discussion, I only understand that
> Ryan Sleevi represents Chrome/Chromium project. And he has perfectly
> expressed his scepticism. What about Mozilla folks - I haven't seen their
> scepticism, may be in another discussion?

I don't believe there's any real interest inside Mozilla in surfacing
GOST to Firefox users for TLS, in part for the reasons indicated by Ryan.

Comment 43

[Max Kosmach]

http://sourceforge.net/projects/atoken/ - An open source implementation of PKCS#11 software device with Russian GOST capabilities.

But PKCS#11 implementation is not enough for current Firefox/Thunderbird.

Comment 44

[Robert Relyea]

PKCS #11 with a plugin to load values in the oid table is almost enough for thunderbird (we also need to tweak with the policy code as well). SSL/TLS also needs a way to add a new cipher suite on the fly. I would restrict it to adding a symetric cipher and perhaps macing based on a cipher class (AEAD, Block, Stream). We may just go with AEAD and stream since I don't think IETF intends to support any new Block ciphers.

Anyway, yes, there is some work to do. I'd be willing to review any patches in that direction.

bob

Comment 45

[Mikhail]

(In reply to Robert Relyea from comment #38)
> As an NSS developer, I'm only interested in adding those algorithms my
> immediate customers (such as Firefox and Thunderbird) want add. I've only
> heard scepticism from Mozilla folks, so I'm not really inclined to pick it
> up into NSS. Even if I did, there is no way to use them if the Firefox team
> doesn't want to turn it on in the browser.

So NSS used not only Firefox and Thunderbird. In my case GOST needed in cURL for B2B interaction. Web service which written in PHP language used cURL library. cURL out of box uses NSS on all modern Linux distributives. 

Probably duplicate of this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=518787

Comment 46

[Mikhail]

You can use follow command for test GOST support in curl
$ curl -F 'test=foo' https://icrs.nbki.ru/products/B2BRequestServlet