Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Chris Richardson]

I believe this plan would have poor side effects. For example, if Apple
ships clients with a broken ECDSA implementation [0], a server cannot
detect detect if a connecting client is an Apple product and avoid the use
of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes
unsafe for anyone to use anywhere.


[0]:
https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d


On Thu, Aug 8, 2013 at 10:30 PM, Brian Smith <br...@briansmith.org> wrote:

> Please see https://briansmith.org/browser-ciphersuites-01.html
>
> First, this is a proposal to change the set of sequence of ciphersuites
> that Firefox offers. Secondly, this is an invitation for other browser
> makers to adopt the same sequence of ciphersuites to maximize
> interoperability, to minimize fingerprinting, and ultimately to make
> server-side software developers and system administrators' jobs easier.
>
> Suggestions for improvements are encouraged.
>
> Cheers,
> Brian
> --
> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>

[Rob Stradling]

On 15/08/13 18:15, Chris Richardson wrote:
> I believe this plan would have poor side effects. For example, if Apple
> ships clients with a broken ECDSA implementation [0], a server cannot
> detect detect if a connecting client is an Apple product and avoid the use
> of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes
> unsafe for anyone to use anywhere.

Chris,

Firefox already offers ECDHE-ECDSA ciphersuites, so I don't think
Brian's plan would introduce any _new_ side effects relating to that OSX
(10.8..10.8.3) bug.

Are you suggesting that Firefox should drop support for all ECDHE-ECDSA
ciphersuites?
Or are you suggesting that NSS should implement the equivalent of that
proposed OpenSSL patch, so that NSS-based TLS servers can avoid
attempting to negotiate ECDHE-ECDSA with broken OSX clients?
Or what?


Should browsers drop support now for all TLS features that might
possibly suffer broken implementations in the future?
(For example, AGL would like to get rid of AES-GCM because it's hard to
implement securely. See
https://www.imperialviolet.org/2013/01/13/rwc03.html)

> [0]:
> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
>
>
> On Thu, Aug 8, 2013 at 10:30 PM, Brian Smith <br...@briansmith.org> wrote:
>
>> Please see https://briansmith.org/browser-ciphersuites-01.html
>>
>> First, this is a proposal to change the set of sequence of ciphersuites
>> that Firefox offers. Secondly, this is an invitation for other browser
>> makers to adopt the same sequence of ciphersuites to maximize
>> interoperability, to minimize fingerprinting, and ultimately to make
>> server-side software developers and system administrators' jobs easier.
>>
>> Suggestions for improvements are encouraged.
>>
>> Cheers,
>> Brian
>> --
>> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
>> --
>> dev-tech-crypto mailing list
>> dev-tec...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

[Ryan Sleevi]

On Fri, August 16, 2013 6:36 am, Rob Stradling wrote:
> On 15/08/13 18:15, Chris Richardson wrote:
> > I believe this plan would have poor side effects. For example, if Apple
> > ships clients with a broken ECDSA implementation [0], a server cannot
> > detect detect if a connecting client is an Apple product and avoid the
> > use
> > of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes
> > unsafe for anyone to use anywhere.
>
> Chris,
>
> Firefox already offers ECDHE-ECDSA ciphersuites, so I don't think
> Brian's plan would introduce any _new_ side effects relating to that OSX
> (10.8..10.8.3) bug.

I think the point was that fingerprinting the TLS handshake has some
positive value, and is not inherently negative - as demonstrated by that
OpenSSL patch.

That's not to suggest that every UA shold report the UA string in the TLS
handshake, but just pointing out that when mistakes (in implementations)
happen, it's "nice" to be able to identify them and work around.

Cheers,
Ryan

[Camilo Viecco]

Hello Brian

I think this proposal has 3 sections.
1. Unifing SSL behavior on browsers.
2. Altering the criteria for cipher suite selection in Firefox (actually
NSS)
3. removing certain cipher suites from the default firefox ciphersuite.

On 1:
I dont see the point, but I am not against.

On 2:
The proposal is not clear. I want an algorithmic definition. For example in
nss we can see in sslenum.c :
-strong ciphers before weaker
- national ciphers before international
- faster ciphers before slow ciphers.

But your proposal it not clear. Here is my reverse engineering of the
criteria to get to your list:

1. Message Authentication: MD5 last.
rationale: security
2. Key exchange (round1): PFS before non-PFS suites
rationale: privacy, goal stop supporting non-PFS suites.
3. Bulk encoding (round1): aes(all variations) before national ciphers
before 3des before rc4 before des before export ciphers before null.
rationale: security, aes is the most studied cipher both in
implementation and theory. RC4 has shown
weakness.
reationale2 performance: 3des is slow and does not provide much
security over the other ciphers.
4. Authentication (round1) : DSS last
rationale: it is not really used, want to deprecate.

5. Key Exchange (round2): ECDH before DHE.
rationale: ECDH allows negotiation form client.
6. Bulk encoding (round 2): 128 AES before 256 AES
rationale: performance and minimal security gains.
7. Message Authentication: authenticated encryption (GCM) before SHA
before SHA256 before sha384
a. AEAD before HMAC : performance
b. sha ordering: performance
8. Authentication: RSA before ECDSA
a. RSA before ECDSA : performance
b. DSA last: not in use

This criteria gets to your ordering proposal. What do you think of
re-framing your list in a criteria like this? (note national ciphers
could go in step 6 instead of step 3).


On 3:
I understand the issues with small packets so I agree we need to prune.
On this
regard:
national ciphers: concur with Gerv need to talk but I am inclined to
remove them
(from the defaults, not from NSS).
removal of null encoding and auth cipher suites: agreed.
Keeping TLS_DHE_DSS_WITH_AES_128_CBC_SHA and the only DSS for
compatibility: agreed
Keeping TLS_RSA_WITH_3DES_EDE_CBC_SHA as the only 3DES for
compatibility: agreed
RC4 cipher agreed:removal agreed.
Not adding any TLS 1.2 cipher that does not use PFS agreed.

Not adding:
TLS_(EC?)DHE_RSA_WITH_AES_(128|256)_CBC_SHA256
Disagree I dont think a potential performance issue should prevent us
from deploying that suite as there could be sha1 attacks that we dont
know of. If we have enough space in the handshake I see no problem in
including them. Removal seems like a premature optimization.

Camilo

On 8/15/13 10:15 AM, Chris Richardson wrote:
> I believe this plan would have poor side effects. For example, if Apple
> ships clients with a broken ECDSA implementation [0], a server cannot
> detect detect if a connecting client is an Apple product and avoid the use
> of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes
> unsafe for anyone to use anywhere.
>
>

[Camilo Viecco]

> 5. Key Exchange (round2): ECDH before DHE. (
And by ECDH I meant ECDHE

[Wan-Teh Chang]

> rationale: ECDH allows negotiation form client.
> 6. Bulk encoding (round 2): 128 AES before 256 AES
> rationale: performance and minimal security gains.
> 7. Message Authentication: authenticated encryption (GCM) before SHA before
> SHA256 before sha384
> a. AEAD before HMAC : performance
> b. sha ordering: performance
> 8. Authentication: RSA before ECDSA
> a. RSA before ECDSA : performance
> b. DSA last: not in use
>
> This criteria gets to your ordering proposal. What do you think of
> re-framing your list in a criteria like this? (note national ciphers could
> go in step 6 instead of step 3).

Camilo, I think you reverse-engineered Brian's criteria correctly.

The new criteria seem fine. I would prefer ECDSA over RSA for authentication.

> Not adding:
> TLS_(EC?)DHE_RSA_WITH_AES_(128|256)_CBC_SHA256
> Disagree I dont think a potential performance issue should prevent us from
> deploying that suite as there could be sha1 attacks that we dont know of. If
> we have enough space in the handshake I see no problem in including them.
> Removal seems like a premature optimization.

The way HMAC-SHA1 uses SHA1 is much more complicated than the way
public key signatures use SHA1. This is why SHA1 collision attacks
usually don't affect the security of HMAC-SHA1.

Wan-Teh

[Rob Stradling]

On 16/08/13 16:18, Ryan Sleevi wrote:
> On Fri, August 16, 2013 6:36 am, Rob Stradling wrote:

>> On 15/08/13 18:15, Chris Richardson wrote:
>>> I believe this plan would have poor side effects. For example, if Apple
>>> ships clients with a broken ECDSA implementation [0], a server cannot
>>> detect detect if a connecting client is an Apple product and avoid the
>>> use
>>> of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes
>>> unsafe for anyone to use anywhere.
>>

>> Chris,
>>
>> Firefox already offers ECDHE-ECDSA ciphersuites, so I don't think
>> Brian's plan would introduce any _new_ side effects relating to that OSX
>> (10.8..10.8.3) bug.
>
> I think the point was that fingerprinting the TLS handshake has some
> positive value, and is not inherently negative - as demonstrated by that
> OpenSSL patch.

Ah, of course. Thanks Ryan.

> That's not to suggest that every UA shold report the UA string in the TLS
> handshake, but just pointing out that when mistakes (in implementations)
> happen, it's "nice" to be able to identify them and work around.

Agreed.

(Now, if I could just persuade the OpenSSL team to commit that patch...
;-) )

> Cheers,
> Ryan
>
>>
>> Are you suggesting that Firefox should drop support for all ECDHE-ECDSA
>> ciphersuites?
>> Or are you suggesting that NSS should implement the equivalent of that
>> proposed OpenSSL patch, so that NSS-based TLS servers can avoid
>> attempting to negotiate ECDHE-ECDSA with broken OSX clients?
>> Or what?
>>
>>
>> Should browsers drop support now for all TLS features that might
>> possibly suffer broken implementations in the future?
>> (For example, AGL would like to get rid of AES-GCM because it's hard to
>> implement securely. See
>> https://www.imperialviolet.org/2013/01/13/rwc03.html)
>>
>>

>>> [0]:
>>> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
>>>
>>>
>>> On Thu, Aug 8, 2013 at 10:30 PM, Brian Smith <br...@briansmith.org>
>>> wrote:
>>>
>>>> Please see https://briansmith.org/browser-ciphersuites-01.html
>>>>
>>>> First, this is a proposal to change the set of sequence of ciphersuites
>>>> that Firefox offers. Secondly, this is an invitation for other browser
>>>> makers to adopt the same sequence of ciphersuites to maximize
>>>> interoperability, to minimize fingerprinting, and ultimately to make
>>>> server-side software developers and system administrators' jobs easier.
>>>>
>>>> Suggestions for improvements are encouraged.
>>>>
>>>> Cheers,
>>>> Brian
>>>> --
>>>> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
>>>> --
>>>> dev-tech-crypto mailing list
>>>> dev-tec...@lists.mozilla.org
>>>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>>>
>>

>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>> Office Tel: +44.(0)1274.730505
>> Office Fax: +44.(0)1274.730909
>> www.comodo.com
>>
>> COMODO CA Limited, Registered in England No. 04058690
>> Registered Office:
>> 3rd Floor, 26 Office Village, Exchange Quay,
>> Trafford Road, Salford, Manchester M5 3EQ
>>
>> This e-mail and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error please notify the
>> sender by replying to the e-mail containing this attachment. Replies to
>> this email may be monitored by COMODO for operational or business
>> reasons. Whilst every endeavour is taken to ensure that e-mails are free
>> from viruses, no liability can be accepted and the recipient is
>> requested to use their own virus checking software.

>> --
>> dev-tech-crypto mailing list
>> dev-tec...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>
>
>

[Rob Stradling]

On 16/08/13 23:05, Wan-Teh Chang wrote:
<snip>

>> 8. Authentication: RSA before ECDSA
>> a. RSA before ECDSA : performance
>> b. DSA last: not in use
>>

<snip>
> ... I would prefer ECDSA over RSA for authentication.

Wan-Teh, why do you think Firefox should specify a preference for ECDSA
over RSA?

If a webserver wants to prefer ECDSA over RSA, then it can override the
browser-supplied cipher-suite order.
e.g. http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslhonorcipherorder

[Wan-Teh Chang]

On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling <rob.st...@comodo.com> wrote:
>
> Wan-Teh, why do you think Firefox should specify a preference for ECDSA over
> RSA?

Because ECDSA is more secure than RSA, and ECC implementations will
become faster over time.

The ordering of RSA and ECDSA is really a "symbolic gesture" right now
because they each require a certificate, and very few websites have
both an RSA certificate and an ECDSA certificate.

Wan-Teh

[Brian Smith]

On Thu, Aug 15, 2013 at 10:15 AM, Chris Richardson <ch...@randomnonce.org>wrote:

> I believe this plan would have poor side effects. For example, if Apple
> ships clients with a broken ECDSA implementation [0], a server cannot
> detect detect if a connecting client is an Apple product and avoid the use
> of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes
> unsafe for anyone to use anywhere.
>

I think your argument is more about the "Future work: A comprehensive
profile for browsers' use of TLS" part of the document, since the
fingerprinting that OpenSSL is now using to detect Safari 10.8 uses the
presence and ordering of TLS extensions like SNI that are not in the scope
of the current proposal. Although I think browsers could now realistically
all agree on the sequence of ciphersuites to offer by default in their
client hello, we're far from standardizing on the contents of the entire
client hello. Let's defer the debate the pros/cons of completely
eliminating fingerprinting in TLS until it is more realistic to do so (if
ever).

Cheers,
Brian

[Brian Smith]

On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco <cvi...@mozilla.com> wrote:

> Hello Brian
>
> I think this proposal has 3 sections.
> 1. Unifing SSL behavior on browsers.
> 2. Altering the criteria for cipher suite selection in Firefox (actually
> NSS)
> 3. removing certain cipher suites from the default firefox ciphersuite.
>

> On 2:
> The proposal is not clear. I want an algorithmic definition.

<snip>

This criteria gets to your ordering proposal. What do you think of
> re-framing your list in a criteria like

this? (note national ciphers could go in step 6 instead of step 3).
>

That sounds reasonable to me. I did not invest too much effort on making
the results computable from the rationale section because I think it is
likely that a lot (or all) of the rationale section would be reduced or
removed from any IETF internet draft that proposed a web browser profile of
TLS.


> On 3:
>
> Not adding:
> TLS_(EC?)DHE_RSA_WITH_AES_(**128|256)_CBC_SHA256

> Disagree I dont think a potential performance issue should prevent us from
> deploying that suite as there could be sha1 attacks that we dont know of.

Now that NSS has AES-GCM, we have an alternative to HMAC-SHA1. Also, if we
are a little presumptuous, we can expect to have a third alternative in
Salsa20/12+(UMAC|VMAC|Poly1305) sometime in the near future. If we find it
is important to offer HMAC-SHA256/384 later, we can do so then. But, if we
add them now, we will have difficulty removing them later.

> If we have enough space in the handshake I see no problem in including
> them.
>

We will have to determine whether the 256-byte client hello limitation is
really something that we have to deal with in the long term. But, even if
that turns out now to be something we need to ever worry about, I would
still be against adding HMAC-SHA256/384 when there seem to be better
alternatives that do not regress performance from what we're offering now.

Cheers,
Brian

[Brian Smith]

I agree that the ordering of ECDSA vs. RSA is mostly a symbolic gesture at
this point in time due to the small number of websites that have both types
of certificates, and the motivations for those sites to have both types.
But, I don't think we should base the order that browsers choose based on
this symbolic meaning; instead, we should base the ordering on what gives
the client the best security/performance/compatibility tradeoff.

I am not sure that we can say that ECDSA is more secure than RSA in a
meaningful way. The old Debian OpenSSL bug and the new Android OpenSSL bug
both offer some empirical evidence that implementation errors in PRNGS are
more likely to reduce security than the theoretical concerns that would
indicate that ECDSA is generally more secure than RSA. Also, the minimum
RSA key size that is acceptable according to the baseline requirements is
2048 bits. For digital signatures, there seems to be quite a significant
margin between what seems to be needed to authenticate a single TLS
handshake and the security level that RSA 2048 offers. If we assume that
websites will generally choose the smallest/fastest key that is considered
acceptable according to the CABForum baseline requirements (RSA 2048 and
ECDSA P-256) then especially on ARM there is quite a performance advantage
for the client to get an RSA signature instead of an ECDSA signature. If
the server is choosing which certificate to use based on the client's
preferences instead of its own performance needs, then the client should be
suggesting what is best for the client, on the assumption that the server
is making a rational decision.

More generally, the ordering I suggested isn't intended to be the ordering
that servers should use if they are configured to disregard the client's
preferences. For example, many servers wouldn't want to choose CBC-based
ciphersuites over RC4 yet if they are concerned about BEAST or Lucky 13.
But, for NSS-based clients, it does make sense to choose the CBC-based
ciphersuites in the proposal over RC4 because the NSS-based clients have
implemented fixes for BEAST and Lucky 13, but not for the RC4 issue.

I will update the proposal to mention these things.

[Gervase Markham]

On 22/08/13 19:21, Robert Relyea wrote:
> The attack profile protection of PFS versus non-PFS is basically two points:
> 1) some government agency could force a server to give up it's private
> keys and decrypt all the traffic sent to that server. But we already
> know that government agencies with such power simply ask for the the
> data on the server.
> 2) some well funded attacker could spend the resources to attack the
> server's private key and get all the traffic sent to it. However, we
> don't actually check to see that the server is giving us a unique key in
> the ephemeral case. A way to cut some of the server cost of DHE/ECDHE is
> to generate a single them key as use it for all connections. We have
> know way of knowing the server is doing this, which brings back this
> particular attack.

3) Someone who has captured some or all of the traffic could use a 0-day
to get into the server and pinch the private key.

This sort of thing is much more likely if the victim is a person of
noteworthiness and the attacker is a government (perhaps that person's
government), but is not the government of the jurisdiction where the
server is based.

As for 2), there are lots of ways a server can sabotage a
seemingly-encrypted connection if it chooses. Why is this one special?

Gerv

[Brian Smith]

On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea <rre...@redhat.com> wrote:

> So looking at this list, I think we have a major inconsistency.
>
> We put Ephemeral over non-ephemeral, but we put 128 over 256.
>
> While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think
> in doing so we are taking a much more significant performance hit we get
> back by putting 128 over 256.
>

It is not exactly true that PFS always has more of a negative performance
impact than AES-128 vs AES-256. In Chromium, PFS ciphersuites will be
faster than non-PFS cipher suites because Chromium requires PFS
ciphersuites to be used for False Start. Also, I have an idea for how we
can make PFS cipher suites + False Start work much more commonly on the
web, that won't work for RSA key exchange. So, ultimately, I expect PFS
cipher suites to be a performance win over non-PFS cipher suites.

But, raw performance isn't the only issue. We expect that PFS cipher suites
*can* have significantly better security properties (see below) if the
server puts in the effort to make the encryption keys actually ephemeral,
and we expect that they are generally no worse they are no worse regarding
security (barring disastrous implementation errors).

Conversely, it isn't clear that AES-256 offers any significant security
advantage over AES-128, though it is clearly slower, even on my
AES-NI-equipped Core i7 processor. First, AES-128 has held up pretty well
so that it might just be "good enough" in general. Secondly, as I already
pointed out in my proposal, some research has shown that AES-256 doesn't
seem to offer much more security than what we understand AES-128 to offer.
See http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html and
https://cryptolux.org/FAQ_on_the_attacks. Thirdly, when non-constant-time
implementations are used, AES-256 seems to offer more opportunity for
timing attacks than AES-128 does, due to more rounds and larger inputs.

> The attack profile protection of PFS versus non-PFS is basically two
> points:
> 1) some government agency could force a server to give up it's private
> keys and decrypt all the traffic sent to that server. But we already
> know that government agencies with such power simply ask for the the
> data on the server.
>

This argument seems to assume that all the data that was transferred over
the network is stored on the server. But, this is not necessarily the case.
I don't think that is a reasonable assumption. The site may have already
deleted the data (perhaps at the request of the user) from the server.
Also, there is a lot of transient data that is never stored anywhere.
Finally, sometimes it is more interesting for the attacker to know what
data was transmitted than to know what data is on the server. For example,
if somebody is trying to prosecute me for posting my album collection to
MegaUpload, the existence of the album data on the MegaUpload server may
not be too useful, whereas a record of me doing the upload of that data
with my actual credentials may be.


> I still think PFS algorithms are useful and agree with preferring them,
> but compared to 128 versus 256 it seems like the cost/security tradeoffs
> are actually less for the PFS algorithms.
>

First, I agree with the overall idea that the performance cost of AES-256
over AES-128 isn't huge. However, I do think that it is significant, at
least for mobile clients where such concerns are most critical--not just
speed, but also battery life. We can gather the numbers (perhaps others
already have them) if that helps.

Something to note is that MSIE has always put AES-128 cipher suites ahead
of AES-128 cipher suites. They also put RSA cipher suites ahead of PFS
cipher suites, though.

Cheers,
Brian

[Brian Smith]

On Mon, Aug 26, 2013 at 2:24 PM, Brian Smith <br...@briansmith.org> wrote:

> Something to note is that MSIE has always put AES-128 cipher suites ahead
> of AES-128 cipher suites. They also put RSA cipher suites ahead of PFS
> cipher suites, though.
>
>

I meant: MSIE has always put AES-128 cipher suites ahead of **AES-256**
cipher suites.

[Kurt Roeckx]

On Mon, Aug 26, 2013 at 05:16:43PM -0700, Robert Relyea wrote:
> 2) It does have a significant downside speed wise. I was responsible
> for measuring this once from the server perspective (we were trying to
> convince people to use ECC. I could only get wins over RSA at the 2048
> bit range with ECDH (224bit) not ECDHE... and that was ECDHE where we
> used a single private key generated at server startup). Note that we are
> using 256 bit ECC at the low end.
>
> Those figures are old, so it would be good to try to get new ones from
> the client perspective (not how many connections a server can use). I'm
> not as worried about the order for servers as servers can manage their
> performance by only supporting the fast algorithms.

See
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

I think this is the most relevant one. Most of the others compare
it to 1024 RSA keys. Only about 4% is still using 1024 keys now,
while the rest is using 2048 or more.


Kurt

[Kurt Roeckx]

So what needs to happen so that we can move on with this?


Kurt

[Julien Vehent]

On 2013-08-26 17:24, Brian Smith wrote:
> Conversely, it isn't clear that AES-256 offers any significant security
> advantage over AES-128, though it is clearly slower, even on my
> AES-NI-equipped Core i7 processor. First, AES-128 has held up pretty well
> so that it might just be "good enough" in general.

I ran some measurements on various CPUs, including slow ones, both with and
without AES-NI. The full table is at the end of this email.
It seems that AES-256 is always 25% to 30% slower than AES-128, regardless
of AES-NI, or the CPU family.
With one exception: AESNI on Intel i7. On this CPU, and for block sizes of
16 64, 256 and 1024 bytes, AES-256 is ~80% slower than AES-128. For a block
size of 8192 bytes, AES-256 is 28.7% slower.

The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which
is probably fast enough for any browser

If performance was the only reason to prefer AES-128, I would disagree with
the proposal. But your other arguments regarding AES-256 not provided
additional security, are convincing.

> Secondly, as I already
> pointed out in my proposal, some research has shown that AES-256 doesn't
> seem to offer much more security than what we understand AES-128 to offer.
> See http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html and
> https://cryptolux.org/FAQ_on_the_attacks. Thirdly, when non-constant-time
> implementations are used, AES-256 seems to offer more opportunity for
> timing attacks than AES-128 does, due to more rounds and larger inputs.
>

This paper: eprint.iacr.org/2007/318.pdf
On the complexity of side-channel attacks on AES-256
- methodology and quantitative results on cache attacks -

Seems to suggest something similar:

In this paper, we addressed side-channel attacks on AES-256: we
demonstrated with
practical results that the complexity (i.e. resistance) increase with
the number of key
bits is virtually non-existent. In particular, for the cache based
attacks, an attack on
AES-256 is only 6 to 7 times as hard as an attack on AES-128 both in the
required
computing power as in the required number of observations. We used the
cache side-
channel as an example side-channel, but the methodology presented in
this work can
be applied to leverage any other channel and attack AES-256.

However, it refers to software implementations of AES. Do we know if this
result still applies for AESNI?

---
Julien Vehent
http://jve.linuxwall.info



--- Speed measurements of AES on several families of CPUs ---

| type | 16_bytes | 64_bytes | 256_bytes | 1024_bytes |
8192_bytes | CPU
-------+-------------+------------+------------+------------+------------+------------+------------------------------------------
AESNI | aes-128-cbc | 669744.67k | 720971.18k | 754488.83k | 758975.49k |
754668.89k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz
AESNI | aes-192-cbc | 580606.16k | 618596.46k | 630121.39k | 630994.60k |
633320.79k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz
AESNI | aes-256-cbc | 507602.55k | 534540.84k | 544787.63k | 540530.35k |
543763.11k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz
regular| aes-128-cbc | 138017.61k | 150701.59k | 154806.19k | 153791.49k |
156374.36k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz
regular| aes-192-cbc | 117436.95k | 126625.64k | 128216.15k | 129753.77k |
130247.34k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz
regular| aes-256-cbc | 102283.73k | 109657.30k | 111773.61k | 112319.15k |
112596.31k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz
-------+-------------+------------+------------+------------+------------+------------+------------------------------------------
AESNI | aes-128-cbc | 574168.83k | 612081.11k | 620871.25k | 626095.10k |
623520.43k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
AESNI | aes-192-cbc | 122382.52k | 130687.70k | 136055.47k | 151552.68k |
395365.03k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
AESNI | aes-256-cbc | 111402.54k | 114350.49k | 125160.36k | 174099.46k |
443987.29k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
regular| aes-128-cbc | 28888.35k | 33039.47k | 86861.99k | 127958.36k |
128316.76k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
regular| aes-192-cbc | 24563.96k | 26540.95k | 32132.95k | 36337.66k |
71385.09k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
regular| aes-256-cbc | 21766.37k | 29087.62k | 26345.47k | 25728.00k |
27989.33k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
-------+-------------+------------+------------+------------+------------+------------+------------------------------------------
AESNI | aes-128-cbc | 27391.57k | 42004.99k | 49039.45k | 51120.81k |
51716.10k | Intel(R) Atom(TM) CPU D510 @ 1.66GHz (NO AESNI SUPPORT)
AESNI | aes-192-cbc | 24954.17k | 36496.21k | 41651.46k | 43204.27k |
43677.01k | Intel(R) Atom(TM) CPU D510 @ 1.66GHz (NO AESNI SUPPORT)
AESNI | aes-256-cbc | 22912.58k | 31863.87k | 35590.14k | 36657.49k |
36975.96k | Intel(R) Atom(TM) CPU D510 @ 1.66GHz (NO AESNI SUPPORT)
regular| aes-128-cbc | 34522.99k | 45628.50k | 49484.20k | 51328.34k |
51764.38k | Intel(R) Atom(TM) CPU D510 @ 1.66GHz (NO AESNI SUPPORT)
regular| aes-192-cbc | 25282.32k | 36839.06k | 41828.18k | 43174.91k |
42999.81k | Intel(R) Atom(TM) CPU D510 @ 1.66GHz (NO AESNI SUPPORT)
regular| aes-256-cbc | 27001.24k | 33287.06k | 36142.25k | 36687.53k |
36713.81k | Intel(R) Atom(TM) CPU D510 @ 1.66GHz (NO AESNI SUPPORT)
-------+-------------+------------+------------+------------+------------+------------+------------------------------------------
AESNI | aes-128-cbc | 21972.35k | 22432.02k | 19986.52k | 54965.25k |
69651.11k | Dual-Core AMD Opteron(tm) Processor 2218 HE (NO AESNI SUPPORT)
AESNI | aes-192-cbc | 43595.54k | 39893.61k | 41966.65k | 92596.73k |
55478.95k | Dual-Core AMD Opteron(tm) Processor 2218 HE (NO AESNI SUPPORT)
AESNI | aes-256-cbc | 25274.79k | 44021.48k | 39315.71k | 70429.35k |
76630.23k | Dual-Core AMD Opteron(tm) Processor 2218 HE (NO AESNI SUPPORT)
regular| aes-128-cbc | 40941.87k | 58502.85k | 53042.12k | 146024.77k |
113713.15k | Dual-Core AMD Opteron(tm) Processor 2218 HE (NO AESNI SUPPORT)
regular| aes-192-cbc | 49289.84k | 43287.83k | 41255.08k | 107338.75k |
95267.50k | Dual-Core AMD Opteron(tm) Processor 2218 HE (NO AESNI SUPPORT)
regular| aes-256-cbc | 36972.34k | 25412.58k | 35431.08k | 69077.82k |
56538.32k | Dual-Core AMD Opteron(tm) Processor 2218 HE (NO AESNI SUPPORT)
-------+-------------+------------+------------+------------+------------+------------+------------------------------------------
AESNI | aes-128-cbc | 38460.22k | 62906.84k | 74712.41k | 78896.13k |
80016.73k | VIA Nano processor U2250 (1.6GHz Capable) (NO AESNI SUPPORT)
AESNI | aes-192-cbc | 35513.85k | 51923.54k | 63855.70k | 65230.85k |
67685.03k | VIA Nano processor U2250 (1.6GHz Capable) (NO AESNI SUPPORT)
AESNI | aes-256-cbc | 32564.81k | 48465.32k | 55756.80k | 58061.48k |
58630.14k | VIA Nano processor U2250 (1.6GHz Capable) (NO AESNI SUPPORT)
regular| aes-128-cbc | 53005.31k | 70560.00k | 77292.46k | 79439.87k |
80218.79k | VIA Nano processor U2250 (1.6GHz Capable) (NO AESNI SUPPORT)
regular| aes-192-cbc | 36862.02k | 55805.35k | 64180.39k | 66947.75k |
67619.50k | VIA Nano processor U2250 (1.6GHz Capable) (NO AESNI SUPPORT)
regular| aes-256-cbc | 34020.35k | 49141.57k | 56039.00k | 58044.76k |
58709.33k | VIA Nano processor U2250 (1.6GHz Capable) (NO AESNI SUPPORT)


command:
# echo "- | type 16_bytes 64_bytes 256_bytes 1024_bytes 8192_bytes"; for
cipher in aes-128-cbc aes-192-cbc aes-256-cbc; do echo -n $(echo -n "AESNI |
"; openssl speed -elapsed -evp $cipher 2>/dev/null|grep ^aes); echo " |
$(grep 'model name' /proc/cpuinfo |cut -d ':' -f 2|uniq)";done; for cipher in
aes-128-cbc aes-192-cbc aes-256-cbc; do echo -n $(echo -n "regular | ";
openssl speed -elapsed $cipher 2>/dev/null|grep ^aes); echo " | $(grep 'model
name' /proc/cpuinfo |cut -d ':' -f 2|uniq)";done

[Julien Pierre]

Julien,

On 9/12/2013 07:06, Julien Vehent wrote:
> If performance was the only reason to prefer AES-128, I would disagree
> with the proposal. But your other arguments regarding AES-256 not
> provided additional security, are convincing.

The performance is still an issue for servers. More servers are needed
if more CPU-intensive crypto algorithms are used.

Julien

[Julien Vehent]

aes-256-cbc with AES-NI does 543763.11kB/s. That's 4.35Gbps of AES bandwidth
on a single core.
On a decent 8 core load balancer, dedicate 4 to TLS, and you get 17.40Gbps
of AES bandwidth.
I don't this AES is close to being the limiting factor here. Processing HTTP
is probably 20 times more expensive than that.

Just reinforcing the point that performance is not, in my opinion, an issue.
The quality of AES-256 is much more relevant here.

[Stefan Arentz]

How about mobile?

What about the initial key exchange that SSL/TLS does? I thought that was the biggest CPU killer?

S.

[Julien Pierre]

Julien,

On 9/12/2013 19:35, Julien Vehent wrote:
> aes-256-cbc with AES-NI does 543763.11kB/s. That's 4.35Gbps of AES
> bandwidth on a single core.
> On a decent 8 core load balancer, dedicate 4 to TLS, and you get
> 17.40Gbps of AES bandwidth.
> I don't this AES is close to being the limiting factor here.
> Processing HTTP is probably 20 times more expensive than that.

That's not correct. Basic HTTP processing is much less CPU intensive
than the overhead of SSL/TLS, regardless of which cipher suite used,
usually by at least an order of magnitude. The crypto is very much the
limiting factor. Choosing a more CPU intensive algorithm will result in
more server hardware being required in general in data centers.

Of course, the server can always disable AES-256 cipher suites
altogether if it doesn't want to spend cycles on it. It would then
choose the AES-128 cipher suites if the client also had them enabled,
which I believe is the case in this proposal. Only an ordering change is
proposed.

Some servers also ignore the order of cipher suites in the Clienthelo
anyway in some cases, and choose whatever they prefer among the client
cipher suite list regardless of order, even though this doesn't follow
the TLS specs.

Julien

[Rob Stradling]

On 13/09/13 04:52, Julien Pierre wrote:
<snip>

> Some servers also ignore the order of cipher suites in the Clienthelo
> anyway in some cases, and choose whatever they prefer among the client
> cipher suite list regardless of order, even though this doesn't follow
> the TLS specs.

Julien, I disagree that this doesn't follow the TLS specs.

RFC5246 (Section 7.4.1.2) says (emphasis mine):
"The cipher suite list, passed from the client to the server in the
ClientHello...
If the list contains cipher
suites the server does not recognize, support, *or wish to use*, the
server MUST ignore those cipher suites, and process the remaining
ones as usual."

[Julien Vehent]

On 2013-09-12 23:11, Stefan Arentz wrote:
> How about mobile?
>

Mobile is not an issue.

Updated table that contains speed test on Android with an ARMv7 (Galaxy S3):
http://jve.linuxwall.info/ressources/taf/aesmeasurements.txt
You can see that the ARM7 does AES-{128,256} in the 50 to 70MB/s range. I
was actually surprised by the results, I had no idea ARMs cpus could compute
AES that fast, and all in software since there's no AES-NI in ARM (yet...).

> What about the initial key exchange that SSL/TLS does? I thought that was
> the
> biggest CPU killer?

Absolutely. And that's still true. I'm only discussing AES-128 vs AES-256
here.


- Julien

[Kurt Roeckx]

On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote:
> So what needs to happen so that we can move on with this?

I still have the same question. Nothing seems to be happening.


Kurt

[Brian Smith]

On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent <jul...@linuxwall.info> wrote:
> It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of AES-NI, or the CPU family.

> The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is probably fast enough for any browser

> If performance was the only reason to prefer AES-128, I would disagree with the proposal. But your other arguments regarding AES-256 not
> provided additional security, are convincing.

> This paper: eprint.iacr.org/2007/318.pdf
> On the complexity of side-channel attacks on AES-256
> - methodology and quantitative results on cache attacks -

Perhaps my arguments were a little over-stated though. The attack I
referenced in the proposal is the related-key attack on reduced-round
AES-256. That is something I should have emphasized. Really, I am
speculating that this shows that thinking AES-256 is hugely more
secure than AES-128 is questionable, but it isn't a slam-dunk case.

The side-channel attack paper you cited seems like the more
interesting one. It doesn't seem like an argument against AES-256 on
its own though, since it still says AES-256 is more difficult to
attack through the given side channels than AES-128.

So, the main remaining question with AES-256 vs. AES-128 is not
whether AES-128 is just as secure as AES-256. Instead, we have to
decide whether AES-256 a better security/performance trade-off vs
AES-128. I agree with you that the performance numbers for AES-256 vs.
AES-128 do not make this a slam-dunk. We should do the measurements on
a typical Firefox OS device and see if there is a significant
difference there. Until then, unless others suggest otherwise, I think
I will just keep the relative ordering of analogous AES-256 and
AES-128 cipher suites the same as they are in NSS today.

> However, it refers to software implementations of AES. Do we know if this
> result still applies for AESNI?

One takeaway from your email is that with AES-NI I don't see a strong
case for prefering AES-128 over AES-256. The issue is really what to
do about the non-AES-NI case, assuming we all agree that the presence
of AES-NI shouldn't affect the order that the client suggests cipher
suites in.

Thank you very much for taking the time to do these measurements and
sharing your insight.

[Trevor Perrin]

On Mon, Oct 7, 2013 at 4:50 PM, Brian Smith <br...@briansmith.org> wrote:

> On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent <jul...@linuxwall.info>
> wrote:
> > It seems that AES-256 is always 25% to 30% slower than AES-128,
> regardless of AES-NI, or the CPU family.
>
> > The slowest implementation of AES-256 has a bandwidth of 21MBytes/s,
> which is probably fast enough for any browser
>
> > If performance was the only reason to prefer AES-128, I would disagree
> with the proposal. But your other arguments regarding AES-256 not
> > provided additional security, are convincing.
>
> > This paper: eprint.iacr.org/2007/318.pdf
> > On the complexity of side-channel attacks on AES-256
> > - methodology and quantitative results on cache attacks -
>
> Perhaps my arguments were a little over-stated though. The attack I
> referenced in the proposal is the related-key attack on reduced-round
> AES-256. That is something I should have emphasized. Really, I am
> speculating that this shows that thinking AES-256 is hugely more
> secure than AES-128 is questionable, but it isn't a slam-dunk case.
>

Hi Brian, all,

Related-key attacks are irrelevant to TLS or any standard use of a block
cipher.

Side-channel attacks against AES just have to recover subkeys from a round
or two, so it's not surprising that the difference between 10-round AES128
and 14-round AES256 doesn't make much of a difference.

Against non-side-channel cryptanalysis of TLS ciphertext, AES-256 certainly
has a higher security margin than AES-128.


Trevor

[Kurt Roeckx]

So it's been 2 months since the last discussion about this. Can
we please move on?


Kurt

[Dirkjan Ochtman]

On Fri, Nov 1, 2013 at 10:22 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
> So it's been 2 months since the last discussion about this. Can
> we please move on?

His Bugzilla status suggests Brian might have left Mozilla:

"Brian Smith (:briansmith, was :bsm...@mozilla.com; NEEDINFO me if you
want a response)"

So that probably doesn't help.

Cheers,

Dirkjan

[Gervase Markham]

On 01/11/13 09:41, Dirkjan Ochtman wrote:
> His Bugzilla status suggests Brian might have left Mozilla:
>
> "Brian Smith (:briansmith, was :bsm...@mozilla.com; NEEDINFO me if you
> want a response)"

No, Brian hasn't left Mozilla - he just decided to use a different
primary email address.

I too would like to see him post a series of "next steps" for this
change. Why can't we just make it (or those bits of it which match the
existing implemented ciphers) tomorrow?

Gerv

[Kurt Roeckx]

On Fri, Nov 01, 2013 at 10:22:22AM +0100, Kurt Roeckx wrote:
> On Mon, Oct 07, 2013 at 09:06:54PM +0200, Kurt Roeckx wrote:
> > On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote:
> > > So what needs to happen so that we can move on with this?
> >
> > I still have the same question. Nothing seems to be happening.
>

> So it's been 2 months since the last discussion about this. Can
> we please move on?

I just found:
https://wiki.mozilla.org/Security/Server_Side_TLS


Kurt

[Brian Smith]

On Fri, Nov 1, 2013 at 2:22 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
> On Mon, Oct 07, 2013 at 09:06:54PM +0200, Kurt Roeckx wrote:
>> On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote:
>> > So what needs to happen so that we can move on with this?
>>
>> I still have the same question. Nothing seems to be happening.
>
> So it's been 2 months since the last discussion about this. Can
> we please move on?

Last week, we enabled TLS 1.2 in Firefox Nightly. Monday's Firefox
Nightly will enable AES-128-GCM and disable the SEED, ECDH, and
DSS_CAMELLIA cipher suites. Firefox Nightly will offer:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Basically, this is what I proposed in my proposal, with some Camellia
and 3DES cipher suites also mixed in, without AES-256-GCM (since NSS
doesn't support it yet), and in a different order. I filed bug 936828
[0]


During IETF88, we learned that the client hello-size-related
interoperability problems may have a very simple workaround; see [1]
and [2]. It is unclear if the workaround provided by F5 will fix all
the size-related ClientHello issues. There appears to be another
problem with Windows Server 2003 [3], but that problem seems unlikely
to affect NSS (at least Firefox) due to the relatively small number of
cipher suites we enable by default.

Last week, I also learned that ENISA, a European standards group,
recommends Camellia alongside AES as a future-proof symmetric cipher
algorithm; see [4]. I think we probably want to still disable Camellia
cipher suites by default in the long term anyway, but I did not
disable them in Firefox Nightly yet. In order for it to make sense to
continue offering Camellia cipher suites long term, we would need to
improve NSS's support for Camellia to add the ECDHE variants of the
Camellia cipher suites. Currently, I think the best course of action
is to let the current configuration ship, then disable Camellia
support, and eventually add ECDHE_*_WITH_CAMELLIA_* support to NSS, so
that it is ready in case some problem with AES is found.

In the IETF88 TLS WG meeting, EKR asked me to write up my proposal as
an internet-draft, so the next revision of the document will be in
that format. I will post it when it is ready.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=936828
[1] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
[2] http://www.ietf.org/mail-archive/web/tls/current/msg10445.html
[3] http://www.ietf.org/mail-archive/web/tls/current/msg10471.html
[4] https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report

[Kurt Roeckx]

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_*

As I already mentioned a few time, I'm still missing some of
the *_AES_*_GCM_* ciphers, specially the DHE ones.

> I think we probably want to still disable Camellia
> cipher suites by default in the long term anyway, but I did not
> disable them in Firefox Nightly yet. In order for it to make sense to
> continue offering Camellia cipher suites long term, we would need to
> improve NSS's support for Camellia to add the ECDHE variants of the
> Camellia cipher suites. Currently, I think the best course of action
> is to let the current configuration ship, then disable Camellia
> support, and eventually add ECDHE_*_WITH_CAMELLIA_* support to NSS, so
> that it is ready in case some problem with AES is found.

I don't understand the part where you want to disable it.


Kurt

[Brian Smith]

On Sun, Nov 10, 2013 at 4:39 AM, Kurt Roeckx <ku...@roeckx.be> 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_*

Thanks. I filed bug 940119 about adding the TLS_ECDHE_*_CAMELLIA_GCM_*
cipher suites.

> As I already mentioned a few time, I'm still missing some of
> the *_AES_*_GCM_* ciphers, specially the DHE ones.

It should be easy to add TLS_DHE_*_GCM_* cipher suites to NSS.

However, I am not sure it is a good idea to add TLS_DHE_*_GCM_* or
TLS_RSA_*_GCM_* cipher suites to Firefox (or other browsers, for that
matter).

Regarding the TLS_DHE_* variants, I think that we should spend some
effort on advocating support for the TLS_ECDHE variants first. In
particular, you mentioned that Apache 2.2 doesn't support ECDHE. Well,
I'd rather work on backporting Apache 2.4's ECDHE support to Apache
2.2 than add the TLS_[DHE_]RSA_*_GCM_* cipher suites to Firefox.
Unfortunately, DHE cipher suites don't work well in current Apache 2.2
either, because of the hard-coded 1024-bit parameters. I don't think
it would be reasonable to backport the better DHE support from Apache
trunk to Apache 2.4 since there are compatibility issues with doing
so. Also, ultimately, we'd like to use TLS_ECDHE_* cipher suites for
performance reasons.

Regarding the TLS_RSA_* variants, like I said before, I think we
should avoid adding new cipher suites for RSA key exchange to Firefox,
to encourage websites to use the ECDHE variants, which help toward
minimizing the fallout of a private key compromise. I am currently
expecting that the One-RTT variant of the TLS 1.3 handshake will
require ECDHE support anyway.

Regardless, I think we can avoid adding those things for now, and
revisit this later when we see what happens with TLS 1.3 and when we
see how successful (or not) our advocacy attempts are.

>> I think we probably want to still disable Camellia
>> cipher suites by default in the long term anyway, but I did not
>> disable them in Firefox Nightly yet. In order for it to make sense to
>> continue offering Camellia cipher suites long term, we would need to
>> improve NSS's support for Camellia to add the ECDHE variants of the
>> Camellia cipher suites. Currently, I think the best course of action
>> is to let the current configuration ship, then disable Camellia
>> support, and eventually add ECDHE_*_WITH_CAMELLIA_* support to NSS, so
>> that it is ready in case some problem with AES is found.
>
> I don't understand the part where you want to disable it.

Originally I was very concerned about the TLS ClientHello message
size, because we were under the impression that we had to keep it
under 256 bytes. That is the reason I prioritized starting this
discussion so highly, in fact. But, at IETF88, we learned that there
may be another workaround to the interop problems such that we don't
have to keep our ClientHello message size under 256 bytes. Still, we
shouldn't be wasteful with our ClientHello message size, since we'll
always want to keep it under ~1400 bytes for performance and
reliability reasons. 1400 bytes might sound like a lot now, but people
have already been talking about TLS extensions that could easily eat
up the majority of that space.

Also, AES implementations are highly optimized, well-audited,
well-tested, and are more likely to be side-channel free. Camellia
doesn't get used very often. Yet, some websites (most famously,
Yahoo!), prefer Camellia over AES, even when we offer AES at higher
priority in the handshake. I am not sure how much the performance or
existence of lack of side-channel-free implementations of Camellia
matter yet. In Firefox, we've kept Camellia enabled for now, and added
some telemetry to measure how often each cipher is used, to inform our
future decision making here.

[Wan-Teh Chang]

On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith <br...@briansmith.org> wrote:
>
> Also, AES implementations are highly optimized, well-audited,
> well-tested, and are more likely to be side-channel free. Camellia
> doesn't get used very often. Yet, some websites (most famously,
> Yahoo!), prefer Camellia over AES, even when we offer AES at higher
> priority in the handshake.

There must be a misunderstanding. NSS offers Camellia at higher
priority than AES in the ClientHello.

Wan-Teh

[Kurt Roeckx]

Yes, in the current stable version camellia is often negiotiated
if the server supports it because it's almost always above the
AES ciphers in the list. The biggest exception to that is ECDHE,
because there is no camellia cipher of that.

I think that the new order makes more sense, and at least in
aurora the order has changed now.


Kurt

[Brian Smith]

On Tue, Nov 19, 2013 at 9:14 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
> On Mon, Nov 18, 2013 at 06:47:08PM -0800, Wan-Teh Chang wrote:
>> On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith <br...@briansmith.org> wrote:
>> >
>> > Also, AES implementations are highly optimized, well-audited,
>> > well-tested, and are more likely to be side-channel free. Camellia
>> > doesn't get used very often. Yet, some websites (most famously,
>> > Yahoo!), prefer Camellia over AES, even when we offer AES at higher
>> > priority in the handshake.
>>
>> There must be a misunderstanding. NSS offers Camellia at higher
>> priority than AES in the ClientHello.

I think you might be right. I remember testing the new cipher suite
order and I was still seeing Camellia being used on
https://login.yahoo.com. But, I tried it again now and it is using AES
with the new cipher suite order. It is very possible that my original
testing of this was off; perhaps due to the HTTP cache or user error.