Closed Bug 940119 Opened 11 years ago Closed 8 years ago

libssl does not support any TLS_ECDHE_*_CAMELLIA_*_GCM cipher suites

Categories

(NSS :: Libraries, enhancement)

Product:
NSS
Component:
Libraries
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: briansmith, Assigned: isk)

References

Details

(Whiteboard: [good first bug])

Attachments

(1 file, 1 obsolete file)

Add TLS_ECDHE_*_CAMELLIA_*_GCM cipher suites.patch
28.60 KB, patch
rrelyea
: review+
Details | Diff | Splinter Review 
We should add support for these cipher suites:

TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384

Rationale: We should support the ECDHE and AES-GCM variants for any symmetric cipher we expect to support long-term. As Camellia seems to have some international support (ENISA, NESSIE, CRYPTREC, at least), it seems reasonable to support it long term.

See bug 880543 and bug 923089. It looks like anybody could implement the AES-128 cipher suites now by copying the work done in bug 880543. If you do that before bug 923089 is fixed, then we can file a follow-up bug for the AES-256 cipher suites.

On dev-tech-crypto, Kurt Roeckx wrote:
> On Sat, Nov 09, 2013 at 02:57:48PM -0800, Brian Smith wrote:
>> Last week, I also learned that ENISA, a European standards group,
>> recommends Camellia alongside AES as a future-proof symmetric cipher
>> algorithm; see [4].
>
> They recommend:
> - *_AES_*_GCM_*
> - *_CAMELLIA_*_GCM_*
> - *_AES_*_CCM_*
I'm interested in fixing this bug.
I'm new to NSS code.
Would you please mentor me?
I make patch.
This patch only for SHA-256 because SHA-384 is not yet supported.
Assignee: nobody → iseki.m.aa
Attachment #8364993 - Flags: review?(brian)
Comment on attachment 8364993 [details] [diff] [review]
Add TLS_ECDHE_*_CAMELLIA_*_GCM cipher suites.patch

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

Thanks for the patch. I suggest that you first read the rest of my comments here and then more carefully study all the patches in bug 880543. Your patch is incomplete because it doesn't do everything that the patches in bug 880543 do.

Also, do you know of a server that supports these cipher suites? Having a link to such a server will be useful for testing.

::: lib/ssl/ssl3con.c
@@ +95,5 @@
>     /* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA is out of order to work around
>      * bug 946147.
>      */
> + { TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256, SSL_ALLOWED, PR_FALSE, PR_FALSE},
> + { TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256,   SSL_ALLOWED, PR_FALSE, PR_FALSE},

These two lines should go above the comment, not below it. That comment is "attached" to the line below.

@@ +406,5 @@
>      {TLS_RSA_WITH_AES_128_GCM_SHA256, cipher_aes_128_gcm, mac_aead, kea_rsa},
>      {TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, cipher_aes_128_gcm, mac_aead, kea_ecdhe_rsa},
>      {TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, cipher_aes_128_gcm, mac_aead, kea_ecdhe_ecdsa},
> +    {TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256, cipher_aes_128_gcm, mac_aead, kea_ecdhe_rsa},
> +    {TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256, cipher_aes_128_gcm, mac_aead, kea_ecdhe_ecdsa},

You need to define a cipher_camellia_128_gcm similar to the definition of cipher_aes_128_gcm.

::: lib/ssl/sslenum.c
@@ +53,5 @@
>      /* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA must appear before
>       * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA to work around bug 946147.
>       */
> +    TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256,
> +    TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256,

Please update the comment that describes the order of the cipher suites in this list, which is located a few lines above. In your update to the comment, note that these cipher suites could be confused with TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA and TLS_PSK_WITH_RC4_128_SHA, respectively when used with the servers that have the problem described in bug 946147.
Attachment #8364993 - Flags: review?(brian) → review-
Sorry to delay.

>Also, do you know of a server that supports these cipher suites?
>Having a link to such a server will be useful for testing.

Sorry, I don't know.
Attachment #8364993 - Attachment is obsolete: true
Attachment #8401793 - Flags: review?(brian)
Comment on attachment 8401793 [details] [diff] [review]
Add TLS_ECDHE_*_CAMELLIA_*_GCM cipher suites.patch

I think we need to find a server to test this against before we continue with this. If no servers support this, then there seems to be little point in doing it. Have you found any servers implementing this yet?
Attachment #8401793 - Flags: review?(brian)
Flags: needinfo?(iseki.m.aa)
Comment on attachment 8401793 [details] [diff] [review]
Add TLS_ECDHE_*_CAMELLIA_*_GCM cipher suites.patch

I didn't mean to clear the review request. I am happy to review it if we can find something using it, and as long as others don't object to adding it.
Attachment #8401793 - Flags: review?(brian)
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #5)
> Comment on attachment 8401793 [details] [diff] [review]
> Add TLS_ECDHE_*_CAMELLIA_*_GCM cipher suites.patch
> 
> I think we need to find a server to test this against before we continue
> with this. If no servers support this, then there seems to be little point
> in doing it. Have you found any servers implementing this yet?

Sorry to delay.
I don't know the server which support this cipher suite.
But GnuTLS support this cipher suite[1]

[1]http://gnutls.org/manual/html_node/Supported-ciphersuites.html
Flags: needinfo?(iseki.m.aa)
(In reply to Masaya Iseki[:isk](UTC+9) from comment #7)
> But GnuTLS support this cipher suite[1]
> 
> [1]http://gnutls.org/manual/html_node/Supported-ciphersuites.html

Botan[2] and PolarSSL[3] also support Camellia GCM cipher suites.

[2]http://botan.randombit.net/manual/tls.html#tls-policies
[3]https://polarssl.org/supported-ssl-ciphersuites

OpenSSL and LibreSSL do not support.
I found a server that supports TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (referring to https://www.ssllabs.com/ssltest/analyze.html?d=blog.benny-baumann.de)
see also bug 1126830
Comment on attachment 8401793 [details] [diff] [review]
Add TLS_ECDHE_*_CAMELLIA_*_GCM cipher suites.patch

Sorry. I had the best intentions, but it's clear I'm never going to have time to review this. And, now I'm no longer an NSS peer so my r+ wouldn't be enough anyway.
Attachment #8401793 - Flags: review?(brian) → review?(rrelyea)
Camellia is modern and standardized cipher (ISO, NESSIE, CRYPTREC and IETF), it uses higher number of rounds than AES, and no attack against ether full Camellia-128 or Camellia-256 is known (SFAIK). In my opinion it should be supported to have at least one cipher coming from non-US expert bodies.

It's usage in TLS context is described in RFC 6367 (https://tools.ietf.org/html/rfc6367) and I think it's GREAT idea to have it included in future releases of NSS, especially the in GCM (AEAD) modes with forward secrecy (TLS_ECDHE_ECDSA_*, TLS_ECDHE_RSA_* and TLS_DHE_RSA_* variants).
Comment on attachment 8401793 [details] [diff] [review]
Add TLS_ECDHE_*_CAMELLIA_*_GCM cipher suites.patch

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

r+, but:
1) It appears that changes to softokn/freebl are missing. I'd like to see those.
2) The switch in ssl3con.c should grab the table driven mechanism out.
3) minor nits about white space, probably space versus tabs issue.

::: lib/ssl/ssl3con.c
@@ +1849,5 @@
>  	    const unsigned char *in,
>  	    int inlen,
>  	    const unsigned char *additionalData,
> +        int additionalDataLen,
> +        SSLCipherAlgorithm calg)

something isn't right with the spacing here...

@@ +1898,5 @@
> +            break;
> +        case calg_camellia_gcm:
> +            mechanism = CKM_CAMELLIA_GCM;
> +            break;
> +    }

Please use the alg2mech array here. That why the next GCM cipher doesn't need to change this code.

@@ +1923,5 @@
>  		  const unsigned char *in,
>  		  int inlen,
>  		  const unsigned char *additionalData,
> +          int additionalDataLen,
> +          SSLCipherAlgorithm calg)

Same spacing problem here as well.
Attachment #8401793 - Flags: review?(rrelyea) → review+
Blocks: 1211248
Masaya, are you still interested in this?
Flags: needinfo?(iseki.m.aa)
No response. Feel free to reopen if you are still working on this.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(iseki.m.aa)
Resolution: --- → INCOMPLETE
For the record, the patch included here is viable and works.
I'm currently forking NSS in my browser to add this support; I would appreciate it if this could be picked up by someone to integrate this in mainstream NSS.
the patch is r+ but there are a couple of things missing as Bob pointed out. It also has to be rebased. If those things get fixed we could land this.
I am not in favor of including this patch. Given that we have both AES and ChaCha, what's the argument for adding another cipher.
(In reply to Eric Rescorla (:ekr) from comment #18)
> I am not in favor of including this patch. Given that we have both AES and
> ChaCha, what's the argument for adding another cipher.

See the rationale in comment 0.
Having globally accepted, modern, strong ciphers supported by the international community in the NSS library is something we'd want. Camellia should certainly fit that bill.
(In reply to Mark Straver from comment #19)
> (In reply to Eric Rescorla (:ekr) from comment #18)
> > I am not in favor of including this patch. Given that we have both AES and
> > ChaCha, what's the argument for adding another cipher.
> 
> See the rationale in comment 0.
> Having globally accepted, modern, strong ciphers supported by the
> international community in the NSS library is something we'd want. Camellia
> should certainly fit that bill.

I'm not finding this convincing. More isn't better in this case and my feeling
is that ChaCha/Poly1305 and AES together provide enough coverage here.
Really? Enough coverage for what, exactly? NSS is used in more than just Mozilla products, you know. I'd appreciate it if you keep that in mind.
There's sites that don't want to use AES for political reasons, for starters.
My feeling is that having exactly one stream and one block cipher to "choose" from doesn't provide enough coverage; and it can even be argued that AES is actually weaker than Camellia.

Now, don't get me wrong, I fully understand the "less is more" approach for these kinds of libraries out of practical considerations for clienthello and similar, but I don't see any convincing argument either why there's such resistance against having this cipher in NSS, and how adding one cipher and not another is anything but an arbitrary choice.
(In reply to Mark Straver from comment #21)
> Really? Enough coverage for what, exactly?

Enough coverage to cover the space of people's requirements.


> NSS is used in more than just
> Mozilla products, you know. I'd appreciate it if you keep that in mind.
> There's sites that don't want to use AES for political reasons, for starters.

And those people can use ChaCha/Poly1305.


> My feeling is that having exactly one stream and one block cipher to
> "choose" from doesn't provide enough coverage; and it can even be argued
> that AES is actually weaker than Camellia.
> 
> Now, don't get me wrong, I fully understand the "less is more" approach for
> these kinds of libraries out of practical considerations for clienthello and
> similar, but I don't see any convincing argument either why there's such
> resistance against having this cipher in NSS, and how adding one cipher and
> not another is anything but an arbitrary choice.

It's not an issue of the size of the ClientHello but of keeping the number
of TLS options to the minimum. We're following the lead of the TLS Working
Group here, and the have converged on AES and ChaCha:

https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-8
> Enough coverage to cover the space of people's requirements.
Apparently it isn't. I don't know what "people" you look at here, but the requirements are there for this cipher or it wouldn't exist, nor be supported by crypto communities around the globe.

> > There's sites that don't want to use AES for political reasons, for starters.
>And those people can use ChaCha/Poly1305.
... As long as their server software actually supports it or the protocol, and as long as the client does too, and as long as this new cipher is trusted by the server operators.

Keeping the number of options to the absolute minimum is nonsense when options are equally strong.

The draft pointed at also deals with a preliminary spec of TLS1.3 that hasn't received any security analysis yet, and that only points out that if no application profile is present that the minimum supported suites are AES-GCM with the recommendation of also adding ChaCha suites. Of note: if no application profile is present determining otherwise. By not having any choice in the matter, you're making the minimum "choice" the only one possible for both client and server employing NSS. Application profile standards won't matter in that case because the option isn't available.

The TLS working group has only converged on AES (and recommendation for ChaCha) as *sane defaults* when nothing has been specified; it doesn't mandate anything beyond that in terms of what should be available or not. This makes it a decision in the hands of implementers, and I guess your decision here is to ignore at least part of the space of people's requirements that may not inherently trust the security of the "latest new cipher". May I remind you that there were no theoretical or practical attacks for AES or RC4 when they were first released either.

I'll leave it at this - sorry for getting a little wordy on this bug, but I feel this is important to stress. I will keep forking NSS for as long as is needed in my own products, but do remind that it's not exactly keeping NSS a relevant choice long-term for implementers if they want to focus on international and liberal use of TLS for serving a broad audience.
(In reply to Mark Straver from comment #23)
> > Enough coverage to cover the space of people's requirements.
> Apparently it isn't. I don't know what "people" you look at here, but the
> requirements are there for this cipher or it wouldn't exist, nor be
> supported by crypto communities around the globe.

Could you please point to some sites that require the Camellia suites?  I'm not aware of any.
exactbins.com for one requires it without question. See bug 1211210 -- I'm sure there are more sites like that, that may not be known to me personally.
There are plenty more that support and prefer Camellia suites. It's part of Japan's e-government sites' Recommended Ciphers, for example.
See also the bug this is a blocker for that has been marked WONTFIX because of the stall here, recently -- it has a bit more info, even if it deals with the CBC variants of Camellia.

This is still a little tangential to my main point though, that having a choice of a strong cipher suite in addition to the absolute minimum is not only desired, it is also a sane thing to do for contingency. Please don't misunderstand this as wanting to replace AES (even if it could), but rather to have the ability to prefer it and use it.
Not to mention the code for the actual cipher itself is already present.
(In reply to Mark Straver from comment #23)
> ... As long as their server software actually supports it or the protocol,
> and as long as the client does too, and as long as this new cipher is
> trusted by the server operators.

Exactly the same goes for ECDHE-CAMELLIA-GCM.

(In reply to Mark Straver from comment #25)
> exactbins.com for one requires it without question.

Looks like it does not support ECDHE-CAMELLIA nor CAMELLIA-GCM, so this bug does not help anyway. And NSS already supports RSA-CAMELLIA-CBC. Firefox will only add PFS/AEAD ciphers (if it does at all), but it does not matter because NSS is not exclusive to Firefox as you said yourself. What's the problem, then?
(In reply to Mark Straver from comment #25)
> exactbins.com for one requires it without question. See bug 1211210 -- I'm
> sure there are more sites like that, that may not be known to me personally.

Given that Chrome doesn't support Camellia either. ISTM that anyone who has
decided to be Camellia only has decided that they don't much care about being
accessible to the broader Web.


> See also the bug this is a blocker for that has been marked WONTFIX because
> of the stall here, recently -- it has a bit more info, even if it deals with
> the CBC variants of Camellia.

Even if NSS supported Camellia, I don't believe that Firefox would
enable it.
> Exactly the same goes for ECDHE-CAMELLIA-GCM.

Camellia has been around for much longer, and has had plenty of time to mature. Trust is inherently going to be less of an issue here.

> Looks like it does not support ECDHE-CAMELLIA nor CAMELLIA-GCM
I'm sure they would support it if clients would actually support it. But even so, this isn't about one site supporting it or not, nor is it about me being able to rattle off sites that require it or not (I have other things to do with my time than gathering metrics about what websites as a whole support). It's about what was clearly looked at as the way forward for Camellia (in the other bug) by adding GCM mode in favor of re-enabling CBC, which I agree with, and that now being blocked after a period of ignoring this bug in favor of ChaCha because Google has pushed that one.

> Even if NSS supported Camellia, I don't believe that Firefox would
enable it.

That doesn't matter. Other products using NSS might want to.
I repeat: Firefox isn't the only thing that uses NSS, so as a library developer you should look a little further than your own backyard. Give us the option to use this cipher suite, without having to make forks, please?
(In reply to Mark Straver from comment #28)
> > Exactly the same goes for ECDHE-CAMELLIA-GCM.
> 
> Camellia has been around for much longer, and has had plenty of time to
> mature. Trust is inherently going to be less of an issue here.

Long floating around code doesn't mean it is safe in the security context. Rather, quite opposite (FREAK, LOGJAM, SLOTH, DROWN, ...). Unused implementations should be actively removed.

> > Looks like it does not support ECDHE-CAMELLIA nor CAMELLIA-GCM
> I'm sure they would support it if clients would actually support it.

How can I confirm? I tried it with gnutls-cli 3.4.9 that should support ECDHE-CAMELLIA-GCM.
> gnutls-cli exactbins.com --priority NONE:+VERS-TLS-ALL:+MAC-ALL:+ECDHE-RSA:+CAMELLIA-128-GCM:+SIGN-ALL:+COMP-NULL:+CURVE-ALL

did not work. If I use RSA-CAMELLIA-CBC, it worked:
> gnutls-cli exactbins.com --priority NONE:+VERS-TLS-ALL:+MAC-ALL:+RSA:+CAMELLIA-128-CBC:+SIGN-ALL:+COMP-NULL

ECDHE-AES-128-GCM also works, for example:
>gnutls-cli www.google.com --priority NONE:+VERS-TLS-ALL:+MAC-ALL:+ECDHE-RSA:+AES-128-GCM:+SIGN-ALL:+COMP-NULL:+CURVE-ALL

> But
> even so, this isn't about one site supporting it or not, nor is it about me
> being able to rattle off sites that require it or not (I have other things
> to do with my time than gathering metrics about what websites as a whole
> support).

Site support matters. If no site (or only one enthusiast's site) supports CAMELLIA-GCM, it would not deserve to add a risk of more attack vectors.

> It's about what was clearly looked at as the way forward for
> Camellia (in the other bug) by adding GCM mode in favor of re-enabling CBC,

You said Firefox support does not matter in the very same comment. Please be consistent.

> which I agree with, and that now being blocked after a period of ignoring
> this bug in favor of ChaCha because Google has pushed that one.

DJB invented ChaCha, not Google, by the way. Google is only promoting.
(In reply to Mark Straver from comment #28)
> > Even if NSS supported Camellia, I don't believe that Firefox would
> enable it.
> 
> That doesn't matter. Other products using NSS might want to.

The text that you are responding to was about a bug asking us to enable
it in Firefox.
Making it an option in Mozilla (not just one product). Whether enabled by default or not doesn't matter for Firefox, now does it?
Anything Mozilla-based does not mean Firefox exclusively. If you're taking that stand then I'm just done. Sad, but I have better ways to use my time.

I see I'm going to have to fight to even have people listen to me, which I'm done with. I'll just keep this patch and apply it every time I pull in a new libssl version, and maintain the fork as-needed, and let someone else try to keep things internationally sane. I just think libssl and NSS is getting more irrelevant if this is the route taken.
(In reply to Mark Straver from comment #31)
> Making it an option in Mozilla (not just one product). Whether enabled by
> default or not doesn't matter for Firefox, now does it?
> Anything Mozilla-based does not mean Firefox exclusively. If you're taking
> that stand then I'm just done. Sad, but I have better ways to use my time.

You really seem determined to misinterpret me. One more time.

1. I think NSS should exercise discretion about what ciphers we add.
This general attitude is also the sense of the TLS WG. 

2. I also think Firefox should exercise discretion about what ciphers
it enables. This may include disabling ciphers which are added to
NSS.

In this particular case, I think that on balance it would be better if
Camellia wasn't in *either* Firefox or NSS. You are of course free to
feel differently, but I don't find your arguments very convincing
since they seem to consist mostly of (a) there are people who don't
trust AES and (b) more is better. In any case, if you convince other
members of the NSS core team, I'll defer to them.
I could say the same about misinterpretation. A library should enable the widest possible sane choices. To draw an analogy: what kind of a library only carries 1 book?

In a nutshell:

1. I think NSS should include all modern, strong cipher suites that have international support and are actively supported by organizations. The determination whether to include a cipher should be made SOLELY based on objective cryptanalysis of the cipher and support by the community, NOT based on popularity.

2. I think Firefox should indeed decide for itself whether to enable certain suites or not.

(1) gives users of NSS the freedom to enable or disable the ciphers based on their own criteria. Your approach, call it discretion if you like, is not treating the library as a library, but rather as a custom module to only fit one product.
(2) should not be a determining factor for (1).

Camellia SHOULD be in in NSS. Whether it is also in Firefox is up to the people in charge of that application.
This bug is about the library - not about the use of it in a certain product.
(In reply to Mark Straver from comment #33)
> I could say the same about misinterpretation. A library should enable the
> widest possible sane choices. To draw an analogy: what kind of a library
> only carries 1 book?
> 
> In a nutshell:
> 
> 1. I think NSS should include all modern, strong cipher suites that have
> international support and are actively supported by organizations. The
> determination whether to include a cipher should be made SOLELY based on
> objective cryptanalysis of the cipher and support by the community, NOT
> based on popularity.

OK, this is not my view, at least not security libraries.

Again, you should feel free to try to convince other members of the NSS core
team.
(In reply to Mark Straver from comment #33)
> A library should enable the widest possible sane choices.

An argument could be made to support Camellia GCM. This is not that argument.

> To draw an analogy: what kind of a library only carries 1 book?

This analogy is nonsense. Libraries of books aren't expected to be responsible for every typo in every book they carry. A security library is very much responsible for every problem in every function it supports.

> 1. I think NSS should include all modern, strong cipher suites that have
> international support and are actively supported by organizations. The
> determination whether to include a cipher should be made SOLELY based on
> objective cryptanalysis of the cipher and support by the community, NOT
> based on popularity.

Camellia does not meet this criteria. It has little to no international support. It started as a national cipher and after many years of Mozilla supporting the CBC mode, it resulted in virtually no support globally, and no support in other libraries. An argument could be made that a new push should be made for GCM. At the moment, however, the support in the community is simply not there.

Arguing for Camellia GCM as an additional backup is one thing, though still a challenge, as it's not all too different from AES. The TLS community, however, has very clearly put its focus on ChaChaPoly as the new cipher to support and is not particularly interested in adding support for old ciphers now with AEAD.

If you're going to lobby for Camellia GCM, you are not going about it in a way which is either working or likely to help your cause.

(For what it's worth, I am neither for nor against Camellia GCM support here.)
When adding examining our protocols we need to balance 2 basic needs: 1) have enough cipher options that we can fail over in the case of cryptographic breakage of one cipher, and 2) not have so many ciphers that our attack surface is to large to manage (as well as limit our ongoing support version).

Under those principles, NSS has never supported every possible cipher (note we don't support perfectly fine ciphers like Idea, RC-5, Blowfish, or Twofish).

Camellia support was originally added because Camellia was strongly sponsored by the Japanese government back when there was some worry about DES. It had a non-insignificant deployment base in Japan, and the code and test cases were supplied in a very clean and very complete patch at the time.

It's use today is not that high as AES has mostly displaced it. If it were brought to us today we not accept it.

Right now Camellia GCM won't give us much more assurance over AES_GCM. they both use the same underlying macing function, and they are both fundamentally block ciphers. ChaCha/Poly has a different algorithm, brought by a respected cryptographer. It has fairly broad support and interest, and it meets the "we need something in case AES or GCM or both fall on it's face".

We've made the same decision on GOST, which has stronger support than Camellia_GCM, so I doubt we'll add Camellia_GCM support to NSS.

bob
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: