144510 - Add support for AES ciphers

Status: VERIFIED DUPLICATE of bug 184940

(Core Graveyard :: Security: UI, defect, P1)

Description

[Kai Engert [:KaiE:]]

AES ciphers should be supported by Mozilla.

Because the new UI implemented in bug 102633 does not work as expected, a new
solution needs to be searched.

However, it is requested that as a temporary measure, the old UI is used to
implement the UI for enabling/disabling the AES ciphers.


Before I can start to work on it, I need the following information:

1.)
===
Please provide the list of NSS' internal cipher identifiers that should be
enabled in PSM. I don't want to make a mistake, and I'd like to ask the NSS team
for help to provide the list of cipher identifiers.

2.)
===
Please decide, which of the ciphers listed in 1.) should become enabled by default.

Comment 1

[Wan-Teh Chang]

Nelson, could you answer Kai's questions 1 and 2?

Kai, I seem to remember Nelson already answered these questions
before, but I can't find the bug number.  Here are my answers
as an initial proposal.

1. I suggest that we add the AES and DHE ciphers to the list.

    TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
    TLS_RSA_WITH_AES_256_CBC_SHA,

    TLS_DHE_DSS_WITH_RC4_128_SHA,
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
    TLS_RSA_WITH_AES_128_CBC_SHA,

    SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
    SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,

    SSL_DHE_RSA_WITH_DES_CBC_SHA,
    SSL_DHE_DSS_WITH_DES_CBC_SHA,

2. I believe the policy is that all new ciphers should be disabled
by default.

Comment 2

[Kai Engert [:KaiE:]]

Wan-Teh: Stephane asked me, as a first step, to only add the AES ciphers.

Comment 3

[Wan-Teh Chang]

Kai,

There are six AES ciphersuites added in NSS 3.4:

    * TLS_DHE_DSS_WITH_AES_128_CBC_SHA
    * TLS_DHE_DSS_WITH_AES_256_CBC_SHA
    * TLS_DHE_RSA_WITH_AES_128_CBC_SHA
    * TLS_DHE_RSA_WITH_AES_256_CBC_SHA
    * TLS_RSA_WITH_AES_128_CBC_SHA
    * TLS_RSA_WITH_AES_256_CBC_SHA

(See the NSS 3.4 Release Notes at
http://www.mozilla.org/projects/security/pki/nss/nss-3.4/nss-3.4-release-notes.html)

Comment 4

[Stephane Saux]

Kai, we all agree here. Please add the cyphers Wan-Teh listed.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Adding Terry Hayes to the cc list.  Terry please add your $.02.

I agree that those are the 6 AES ciphersuites, and I agree that it's
OK to add them to the UI so they can be enabled or disabled by the user.

However, I believe it is still appropriate that these ciphersuites 
should not be enabled by default.  The reason is that the IETF TLS working
group has recently been considering changing the definition of these 
cipher suites, to make them work differently than the present Internet
Draft specifies (which is what we implement).  

If the TLS WG does change the definition, then our product will have an 
implementation that does not conform to the then-current definition.  In 
that event, all users of our implementation of the AES ciphersuites would 
need to disable those ciphersuites to avoid interoperability problems with 
servers that implement the new definition.  Users who enabled those AES
ciphersuites themselves, manually, will presumably be able to disable them
without a lot of hand holding.  But if we enable those ciphersuites by 
default, then users will have to disable who have never before enabled or
disabled any ciphersuite.  This will require lots of hand-holding, read
support costs.  

So, I believe that Netscape/Mozilla products should not enable the AES
ciphersuites by default until the AES ciphersuite definition is truly
final.

Comment 6

[Terry Hayes]

I agree with Nelson's comments on the default setting for the AES ciphers. 
Until the AES ciphersuites are defined in an RFC (rather than a draft) we should
leave them off by default.

I see that kaie already changed the summary line to reflect this position, so we
all seem to be in agreement.

Comment 7

[Kai Engert [:KaiE:]]

*** Bug 100698 has been marked as a duplicate of this bug. ***

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

In June 2002, the AES ciphersuite document became RFC 3268, a proposed 
standard.  http://www.rfc-editor.org/rfc/rfc3268.txt
I will review it to see if there were any last minute changes.
If not, then I believe NSS is already compliant with this RFC,
and in that case, we should now consider enabling the AES ciphersuites
by default in our products.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

I believe NSS 3.4 - 3.6 are compliant with RFC 3268 for the subset of the 
defined AES ciphersuites that were implemented, namely

TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,

The DHE ciphersuite implementations are presently client-side only.

Comment 10

[Stephane Saux]

set for 2.4

Comment 11

[Kai Engert [:KaiE:]]

This will be done as part of bug 184940.


*** This bug has been marked as a duplicate of 184940 ***

Comment 12

[John Unruh]

Verified dupe.