Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

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)

[Gervase Markham]

Hi Brian,

On 09/08/13 03:30, Brian Smith wrote:
> Please see https://briansmith.org/browser-ciphersuites-01.html

....

> Suggestions for improvements are encouraged.

Thanks for this. Here are my questions:

* Can you provide some background or references on exactly how
ciphersuite construction and choice works? Can I invent e.g.
TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of
elements? Can any combination be encoded in the ClientHello? Does the
server support specific sets, or will it support my combination if it
supports all the component pieces?

* "We should avoid leaking the distinction between mobile and desktop
products in the TLS handshake, which means that the handshake should
look the same on mobile and desktop."

Why is this a goal? There are many, many other ways of determining this
distinction, some supported by Mozilla (e.g. the UserAgent string).

This is not to deny that there are other reasons for having a consistent
set, but this seems an odd one.

The same question applies to your point about avoiding TLS
fingerprinting. I think it should be a goal to make it hard to
distinguish between specific instances of Firefox, but it seems to be
not a goal to avoid people distinguishing between Firefox and IE, or
Firefox for desktop and Firefox for Android.

* "this proposal does not recommend supporting the CBC-HMAC-SHA-2-based
ciphersuites that those browsers recently added"

Can you spell out why? Is it because they don't offer forward secrecy?

* "In the course of testing TLS 1.2 and the ALPN TLS extension, the
Chromium team recently found that some servers choke when the
ClientHello message in the TLS handshake is larger than 256 bytes."

How many bytes are taken up per ciphersuite? How many can we probably
fit in, if we say we need to include all the other stuff?

* Re: Camellia and SEED: we should talk to the organisations which
pushed for their addition, and our business development people in the
region, before eliminating them. (This is not to say that we will
definitely not remove them if they raise objections.)

* "Given our current understanding, HMAC-SHA-1, HMAC-SHA-256, and
HMAC-SHA-384 are all more-or-less equal in terms of security given how
they are used in TLS."

However, if we never use them, then have to switch to them because a
problem arises with HMAC-SHA-1, how will they have received any testing?

More generally, is there a place for including ciphersuites 'of the
future', perhaps at lower priority, to try and make sure there aren't
problems or interop issues with them?

* Your final section says what cipersuites should be added and dropped.
Is this simply a config change with testing, or does it require code to
be written in one or more of the TLS stacks?

Gerv

[Brian Smith]

On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham <ge...@mozilla.org> wrote:

> * Can you provide some background or references on exactly how
> ciphersuite construction and choice works? Can I invent e.g.
> TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of
> elements? Can any combination be encoded in the ClientHello? Does the
> server support specific sets, or will it support my combination if it
> supports all the component pieces?
>

No, each combination is hard-coded into its own distinct code point that is
registered with IANA:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4.
This is a design choice based on the fact that many crypto modules don't
let you mix/match algorithms at will, and because you often can't/shouldn't
move keys between crypto modules.

> * "We should avoid leaking the distinction between mobile and desktop
> products in the TLS handshake, which means that the handshake should
> look the same on mobile and desktop."
>
> Why is this a goal? There are many, many other ways of determining this
> distinction, some supported by Mozilla (e.g. the UserAgent string).
>

There is a difference between leaking to somebody on the network and
leaking to the server you are connecting to. Remember that TLS hides the
User-Agent string and other HTTP-level information is hidden from others on
the network. So, if Firefox for Android and Firefox for Desktop use the
exact same TLS handshaking logic/parameters, then it should be possible to
make them indistinguishable from each other.

> The same question applies to your point about avoiding TLS
> fingerprinting. I think it should be a goal to make it hard to
> distinguish between specific instances of Firefox, but it seems to be
> not a goal to avoid people distinguishing between Firefox and IE, or
> Firefox for desktop and Firefox for Android.
>

If every browser's TLS handshake were to look the same, then observers on
the network wouldn't be able to tell browsers apart, though the website you
are connecting to obviously would. I admit that is a state that is likely
to be difficult to obtain.

* "this proposal does not recommend supporting the CBC-HMAC-SHA-2-based
> ciphersuites that those browsers recently added"
>
> Can you spell out why? Is it because they don't offer forward secrecy?
>

It is explained below. Worse performance, no security benefit, and they
take up space in the handshake.

> * "In the course of testing TLS 1.2 and the ALPN TLS extension, the
> Chromium team recently found that some servers choke when the
> ClientHello message in the TLS handshake is larger than 256 bytes."
>
> How many bytes are taken up per ciphersuite? How many can we probably
> fit in, if we say we need to include all the other stuff?
>

They take two bytes per ciphersuite. If the 256-byte limitation cannot be
worked around, then we basically can't afford to waste *any* bytes in the
TLS handshake. It is already likely going to be very difficult for us to
support the ALPN extension as it is, even after making these reductions.

> * Re: Camellia and SEED: we should talk to the organisations which
> pushed for their addition, and our business development people in the
> region, before eliminating them. (This is not to say that we will
> definitely not remove them if they raise objections.)
>

Do you have suggestions for who to contact?

> * "Given our current understanding, HMAC-SHA-1, HMAC-SHA-256, and
> HMAC-SHA-384 are all more-or-less equal in terms of security given how
> they are used in TLS."
>
> However, if we never use them, then have to switch to them because a
> problem arises with HMAC-SHA-1, how will they have received any testing?
>


>
> More generally, is there a place for including ciphersuites 'of the
> future', perhaps at lower priority, to try and make sure there aren't
> problems or interop issues with them?
>

We will soon have AES-GCM and we'll hopefully soon have
Salsa20/12+(Poly1305|UMAC|VMAC) to mitigate that. Relying on either/both of
those alternatives kills more birds with fewer stones. I think ultimately
we'd rather have all HMAC-based ciphersuites also marked deprecated, for
performance and security reasons.

> * Your final section says what cipersuites should be added and dropped.
> Is this simply a config change with testing, or does it require code to
> be written in one or more of the TLS stacks?
>

Dropping ciphersuites is a simple configuration change.

In the top table, the "notes" column lists the ciphersuites that will
require code changes to NSS and to SChannel. Bug
880543<https://bugzilla.mozilla.org/show_bug.cgi?id=880543>tracks the
addition of AES-GCM ciphersuites to NSS's libssl. OpenSSL
already implements them. I think Google may be working on
Sals20/12+Poly1305 ciphersuites and there has been some small progress on
adding Sals20/12 ciphersuites in the IETF TLS working group.

Reordering ciphersuites in SChannel can be done with a configuration change
to the app. Reordering ciphersuites in NSS either requires us to reorder
them for all apps, or to add an API to customize the order to libssl. I
would prefer to change the order in NSS itself.

Cheers,
Brian

[Brian Smith]

[Tom Ritter]

Thoughts, as a random passerby:

Of course I quite like the prioritization of (EC)DHE.

I think standardizing on a ciphersuite preference order with the aims
of reducing fingerprinting is a worthwhile (although wildly difficult)
goal for SSL _libraries_, but less so for browsers - to the point of
probably not being a fight worth fighting. A web browser is so
incredibly complex it is next to impossible to browse with _soley_
over TLS, and the first HTTP request leaks the User Agent. Even with
soley-over-TLS, requests for malware protection, the dynamic favorites
RSS feeds Firefox bundles (which I quite hate), and the auto-update
checks will leak the browser anyway. Trying to avoid leaking the
preference to the network is admirable, and worthwhile in a library I
think, but the browser is a mighty beast to tackle. There are lower
hanging fruit than the TLS handshake right now.

Weak DHE keys are a lurking problem. Someone needs to survey the
internet. (Unless there's a paper I'm not aware of...)

The Ephemeral ECDH certs is clever... but I feel like that's an awful
amount of engineering for the relatively few organizations who their
own Intermediate cert. Unless this is a strategic push to encourage
Name Constraints. In which case: Hmmmmmm.

"Future work: A comprehensive profile for browsers' use of TLS." - In
theory, this would be the domain of the relatively-new IETF PKI
Operations Working Group, which is being driven by a few browser folks
and many CA folks.

I would suggest another item for "Future Work" and that is trying to
work in protections against TLS downgrades. This has been batted
around a few times in the past [0][1] but has never gained much
traction or agreement.

-tom

[0] https://www.ietf.org/mail-archive/web/tls/current/msg08861.html
[1] I'm failing to find a link, but Yoav had a trick he added to Opera
to prevent downgrade if the server supported secure renegotiation.

[Tom Ritter]

[Gervase Markham]

On 09/08/13 18:12, Brian Smith wrote:
> No, each combination is hard-coded into its own distinct code point that is
> registered with IANA:
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4.
> This is a design choice based on the fact that many crypto modules don't
> let you mix/match algorithms at will, and because you often can't/shouldn't
> move keys between crypto modules.

OK. So you are choosing from a fixed palette, and changing that palette
is outside the scope of this proposal?

> There is a difference between leaking to somebody on the network and
> leaking to the server you are connecting to. Remember that TLS hides the
> User-Agent string and other HTTP-level information is hidden from others on
> the network. So, if Firefox for Android and Firefox for Desktop use the
> exact same TLS handshaking logic/parameters, then it should be possible to
> make them indistinguishable from each other.

I agree this is theoretically possible but, as Tom points out, if we
posit an attacker who can see your traffic, the chances of you
concealing the identity of your user agent from him are pretty small.

When risk is there to a user of having a network eavesdropper able to
tell that they are using a particular browser? If I had an exploit for a
particular browser, I'd just try it anyway and see if it worked. That
seems to be the normal pattern.

>> * Re: Camellia and SEED: we should talk to the organisations which
>> pushed for their addition, and our business development people in the
>> region, before eliminating them. (This is not to say that we will
>> definitely not remove them if they raise objections.)
>
> Do you have suggestions for who to contact?

The first person I would talk to would be Gen Kanai <g...@mozilla.com>,
although he may put you in touch with others.

Gerv

[Brian Smith]

On Mon, Aug 12, 2013 at 6:52 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 09/08/13 18:12, Brian Smith wrote:

> > No, each combination is hard-coded into its own distinct code point that
> is
> > registered with IANA:
> >
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
> .
> > This is a design choice based on the fact that many crypto modules don't
> > let you mix/match algorithms at will, and because you often
> can't/shouldn't
> > move keys between crypto modules.
>

> OK. So you are choosing from a fixed palette, and changing that palette
> is outside the scope of this proposal?
>

It is possible to add new cipher suites, but new cipher suites should have
substantial value and a realistic shot at becoming widely-deployed.

> I agree this is theoretically possible but, as Tom points out, if we
> posit an attacker who can see your traffic, the chances of you
> concealing the identity of your user agent from him are pretty small.
>
> When risk is there to a user of having a network eavesdropper able to
> tell that they are using a particular browser? If I had an exploit for a
> particular browser, I'd just try it anyway and see if it worked. That
> seems to be the normal pattern.
>

One example is Tor: it tries to look like "a normal browser" so that it is
hard to detect that you are using Tor. And, if Tor is properly configured
then the network attacker will never see any non-TLS traffic.

> >> * Re: Camellia and SEED: we should talk to the organisations which
> >> pushed for their addition, and our business development people in the
> >> region, before eliminating them. (This is not to say that we will
> >> definitely not remove them if they raise objections.)
> >
> > Do you have suggestions for who to contact?
>

> The first person I would talk to would be Gen Kanai <g...@mozilla.com>,
> although he may put you in touch with others.
>

Thanks. I will send ask him to forward a link to these threads to the
people he thinks may be interested in it.

Cheers,
Brian

[Brian Smith]

On Mon, Aug 12, 2013 at 6:52 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 09/08/13 18:12, Brian Smith wrote:

> > No, each combination is hard-coded into its own distinct code point that
> is
> > registered with IANA:
> >
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
> .
> > This is a design choice based on the fact that many crypto modules don't
> > let you mix/match algorithms at will, and because you often
> can't/shouldn't
> > move keys between crypto modules.
>

> OK. So you are choosing from a fixed palette, and changing that palette
> is outside the scope of this proposal?
>

It is possible to add new cipher suites, but new cipher suites should have
substantial value and a realistic shot at becoming widely-deployed.


> I agree this is theoretically possible but, as Tom points out, if we
> posit an attacker who can see your traffic, the chances of you
> concealing the identity of your user agent from him are pretty small.
>
> When risk is there to a user of having a network eavesdropper able to
> tell that they are using a particular browser? If I had an exploit for a
> particular browser, I'd just try it anyway and see if it worked. That
> seems to be the normal pattern.
>

One example is Tor: it tries to look like "a normal browser" so that it is
hard to detect that you are using Tor. And, if Tor is properly configured
then the network attacker will never see any non-TLS traffic.

> >> * Re: Camellia and SEED: we should talk to the organisations which
> >> pushed for their addition, and our business development people in the
> >> region, before eliminating them. (This is not to say that we will
> >> definitely not remove them if they raise objections.)
> >
> > Do you have suggestions for who to contact?
>

[Kurt Roeckx]

On 08/09/2013 04:30 AM, Brian Smith 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.

So I think there are a whole bunch of things where we have 2 options,
and it's not always clear which is more important. We have:
- PFS or not
- ECC or not
- RSA or DSA
- GCM or CBC
- keysize (128 vs 256)
- cipher itself
- The used MAC

As far as I understand things, most of those don't have a big impact on
security, but do on the speed.

I think it makes sense to have PFS when the other side supports it, so
that part of the order looks good to me. We clearly want (EC)DHE when
possible. DH should probably be avoided.

I understand that ECC might be more secure and is faster, so you want to
prefer ECC. But currently there aren't many servers that have ECDHE
yet, so we should be careful what the order is in case it's not
available and try to use DHE in that case. The current list didn't do
that but this one does.

I'm not sure which of RSA and DSA is better, but clearly people use RSA
more.

I understand that GCM is faster, but the implementations might have side
channel attacks. So I'm not sure if GCM or CBC is better, but
we should probably prefer GCM or CBC.

I understand that for a 2048 bit public key a 128 bit symmetric key
should be good enough, but for a 4096 you should have a larger key. I
see that about 2% is using keys of 4096 bit.

As far as I understand it, there is nothing wrong with 3DES other than
that it's slower. RC4 should clearly be deprecated, but is currently
popular because BEAST and that it's the only stream cipher we have.
Since we know we're not vulnerable to that, it make sense to order this
as late as possible.

It might not be obvious, but camellia is currently used a lot when
connecting to sites because it's the first non-ECDHE in the current
list. And the RSA key-exchange was even before the DHE version.

I understand that the MAC itself doesn't make much difference, but we
should probably avoid MD5. I see no SHA256 MACs except for GCM which
probably isn't a problem.

So I can mostly follow the reasoning behind the proposed order, but I'm
a little bit surprised that we used to have all the 256 bit before the
128 bit, and it's now the other way around. I don't really see this as
a problem except for people that want to use 4096 bit public keys. They
should probably disable 128 bit keys on their server.

I'm not sure why you keep
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
and drop
TLS_DHE_DSS_WITH_AES_256_CBC_SHA

I'm concerned that DHE_RSA_WITH_3DES_EDE_CBC_SHA is dropped, since it's
the only one with PFS that some sites support. Can I suggest you add
that before the ECDHE_*_RC4 ciphers?


Kurt

[Kurt Roeckx]

On Mon, Aug 19, 2013 at 08:06:49PM +0200, Kurt Roeckx wrote:
> I understand that the MAC itself doesn't make much difference, but
> we should probably avoid MD5. I see no SHA256 MACs except for GCM
> which probably isn't a problem.

I'm having mixed feelings about SHA1 / SHA256. I think it makes
sense to move to SHA256 even when SHA1 isn't broken as used here.
But since we do this already use it for GCM, and that's on top of
the list, I think it's fine.

> I'm concerned that DHE_RSA_WITH_3DES_EDE_CBC_SHA is dropped, since
> it's the only one with PFS that some sites support. Can I suggest
> you add that before the ECDHE_*_RC4 ciphers?

I also just noticed that all GCM suites we have are ECDHE
versions. I would like to have a DHE version too since
apache 2.2 doesn't support ECDHE but does have support
for the DHE GCM ciphers. I would like to see that as first
non-ECDHE cipher in the list.


Kurt

[Gervase Markham]

On 19/08/13 04:07, Brian Smith wrote:
>> When risk is there to a user of having a network eavesdropper able to
>> tell that they are using a particular browser? If I had an exploit for a
>> particular browser, I'd just try it anyway and see if it worked. That
>> seems to be the normal pattern.
>
> One example is Tor: it tries to look like "a normal browser" so that it is
> hard to detect that you are using Tor. And, if Tor is properly configured
> then the network attacker will never see any non-TLS traffic.

But if Tor Browser is based on Firefox, then it'll have the same TLS
signature as Firefox anyway?

Gerv

[Tom Ritter]

On 20 August 2013 14:26, Gervase Markham <ge...@mozilla.org> wrote:
> On 19/08/13 04:07, Brian Smith wrote:

>>> When risk is there to a user of having a network eavesdropper able to
>>> tell that they are using a particular browser? If I had an exploit for a
>>> particular browser, I'd just try it anyway and see if it worked. That
>>> seems to be the normal pattern.
>>
>> One example is Tor: it tries to look like "a normal browser" so that it is
>> hard to detect that you are using Tor. And, if Tor is properly configured
>> then the network attacker will never see any non-TLS traffic.
>

> But if Tor Browser is based on Firefox, then it'll have the same TLS
> signature as Firefox anyway?

Not Tor Browser, but the Tor protocol itself. For more information,
the spec document that deals with this is:
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/198-restore-clienthello-semantics.txt

-tom

[Tom Ritter]

On 20 August 2013 14:26, Gervase Markham <ge...@mozilla.org> wrote:
> On 19/08/13 04:07, Brian Smith wrote:

>>> When risk is there to a user of having a network eavesdropper able to
>>> tell that they are using a particular browser? If I had an exploit for a
>>> particular browser, I'd just try it anyway and see if it worked. That
>>> seems to be the normal pattern.
>>
>> One example is Tor: it tries to look like "a normal browser" so that it is
>> hard to detect that you are using Tor. And, if Tor is properly configured
>> then the network attacker will never see any non-TLS traffic.
>

[Alan Braggins]

On 19/08/13 19:06, Kurt Roeckx wrote:
> I understand that GCM is faster, but the implementations might have side
> channel attacks. So I'm not sure if GCM or CBC is better, but
> we should probably prefer GCM or CBC.

GCM (while recognizing that it isn't widely supported yet).

(At least unless
http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-00
gets anywhere - the current choice isn't so much "GCM or CBC" as
"GCM or MAC-then-encrypt-CBC".
Personally I don't see very much point in Peter's proposal - supporting
the new extension won't be that much less work than GCM, and GCM suites
are already standardized.)

[Zack Weinberg]

On 2013-08-19 2:06 PM, Kurt Roeckx wrote:
>
> I understand that GCM is faster, but the implementations might have side
> channel attacks. So I'm not sure if GCM or CBC is better, but
> we should probably prefer GCM or CBC.

GCM is (AIUI) preferred because it's immune to BEAST. I share concern
about new side channel attacks due to GMAC, though.

> As far as I understand it, there is nothing wrong with 3DES other than
> that it's slower.

I am under the impression that the 64-bit block size is also considered
a serious flaw nowadays.

zw

[Zack Weinberg]

I expect if all the browsers change their ciphersuite selection, Tor
will follow suit. Looking like an *old* browser would eventually become
suspicious.

zw

[Alan Braggins]

On 21/08/13 18:23, Zack Weinberg wrote:
> On 2013-08-19 2:06 PM, Kurt Roeckx wrote:
>>

>> I understand that GCM is faster, but the implementations might have side
>> channel attacks. So I'm not sure if GCM or CBC is better, but
>> we should probably prefer GCM or CBC.
>

> GCM is (AIUI) preferred because it's immune to BEAST.

The TLS1.1 explicit IV is sufficient for immunity to that
specific attack even when using CBC mode.
http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack

> I share concern
> about new side channel attacks due to GMAC, though.

You aren't alone.
https://bugzilla.mozilla.org/show_bug.cgi?id=868948

salsa20 + poly1305 anyone?

[Kurt Roeckx]

On Thu, Aug 22, 2013 at 10:35:33AM -0700, Robert Relyea wrote:

> On 08/19/2013 11:06 AM, Kurt Roeckx wrote:
> > I understand that ECC might be more secure and is faster, so you want
> > to prefer ECC. But currently there aren't many servers that have ECDHE
> > yet, so we should be careful what the order is in case it's not
> > available and try to use DHE in that case. The current list didn't do
> > that but this one does.
>

> This is ECC marketing. When we did the measurements (10 years ago), RSA
> was significantly faster on modern 64-bit machines than ECC at the 1024
> bit level, and a push at the 2048 bit level (this is measuring SSL
> connection performance). That is assuming ECDH. ECDHE is 3 times slower
> than ECDHE. RSA gets a one for one performance boost every time you
> increase the speed of the modular multiply. where as ECC only gets 20%
> or so of that.

Some stats I've seen show ECDHE being almost 3 times faster than
DHE for 2048 bits. ECDHE is slower than an RSA key exchange, but
it's something like 10-20%.

> The ECC win is that ECC is more secure at lower key sizes, and it's
> security profile is linear. RSA's security profile is exponential:
> Example of typical equivalences:
>
> Symmetric 80 ECC 160 RSA 1024
> Symmetric 128 ECC 256 RSA 2048
> Symmetric 192 ECC 384 RSA 4096
> Symmetric 256 ECC 512* RSA 8K

It's not exactly the numbers I've seen, the RSA values I've seen
are higher, but I guess this is good enough. No problem with
being more conservative.

> > I understand that for a 2048 bit public key a 128 bit symmetric key
> > should be good enough, but for a 4096 you should have a larger key. I
> > see that about 2% is using keys of 4096 bit.
>

> It's a question of where your weakest link is. 2048 matches better with
> 256 than 128. 4096 bit keys are overkill for a server leaf certificate.

Not according to your own table above.

What I'm saying is that for a 4096 bit RSA key, the 128 symmetric
key would be weaker and we probably want to use a 256 key in that
case. But for a 2048 bit RSA key a 128 symmetric should be
enough.


Kurt

[hsiv...@hsivonen.fi]

On Friday, August 9, 2013 5:30:26 AM UTC+3, Brian Smith wrote:
> Please see https://briansmith.org/browser-ciphersuites-01.html

Thank you for this.

I'm a bit skeptical about whether eliminating handshake fingerprinting is worth the disincentive to improve the set of ciphersuites. And I'm skeptical about actually getting to a state where all browsers have the same handshake in the first place.

If there was a single ciphersuite that was known to be the one everyone should use for all future and the other ciphersuites were around just for compatibility with legacy servers (analogous to UTF-8 and other character encodings), I think it would make sense to freeze the handshake. However, since encryption is supposed to get stronger over time, having a frozen handshake would block improvements. Is it really realistic that other browsers would agree not to offer better ciphersuites as soon as they can get them implemented until all browsers agree that new ciphersuites should be included? On the other hand, if other browsers adopted the same handshake as Firefox, would it be better for Firefox to keep the common handshake than to introduce better ciphersuites as they become available?

If the common handshake isn't achievable or desirable, I wonder if it's a good idea to drop Camellia altogether. I know nothing about the merits of Camellia relative to AES (maybe they are even similar enough for attacks to be transferable; dunno), but a reduction in algorithm agility seems scary on an uninformed gut level. If one assumes that handshakes won't be unified across browsers, wouldn't it then make sense, space permitting, to keep around at least one forward-secret RSA+Camellia ciphersuite in case a disaster strikes AES?

What the threat being defended against in the handshake fingerprinting case? At least network eavesdroppers near the browser will have plenty of adjacent plain HTTP traffic with UA strings to capture for the foreseeable future and the site being connected to gets the UA string anyway.

[Alan Braggins]

I asked a friend who works for ARM about the chances of
constant time AES-GCM instruction set support.
"SecurCore; sure. A-series; no chance."

I'm not convinced that the advantages of eliminating
handshake fingerprinting outweigh the benefits of
allowing endpoints with different capabilities to
negotiate different ciphers (e.g. preferring AES more
strongly if AES-NI instructions are available at both
ends).

Possibly you should be aiming for a shared set of principles
to be used by browsers when choosing a suite, not a shared
ordering.

[Gervase Markham]

On 09/08/13 03:30, Brian Smith wrote:
> Please see https://briansmith.org/browser-ciphersuites-01.html

This proposal promotes ECC.

http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance

Schneier: "Prefer conventional discrete-log-based systems over
elliptic-curve systems; the latter have constants that the NSA
influences when they can."

He elaborates in the comments:

"I no longer trust the constants. I believe the NSA has manipulated them
through their relationships with industry."

Does that affect your proposal?

Gerv

[Dirkjan Ochtman]

On Mon, Sep 9, 2013 at 5:16 PM, Gervase Markham <ge...@mozilla.org> wrote:
> This proposal promotes ECC.
>
> http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
>
> Schneier: "Prefer conventional discrete-log-based systems over
> elliptic-curve systems; the latter have constants that the NSA
> influences when they can."
>
> He elaborates in the comments:
>
> "I no longer trust the constants. I believe the NSA has manipulated them
> through their relationships with industry."
>
> Does that affect your proposal?

I don't think other prominent cryptographers necessarily agree:

http://www.slideshare.net/astamos/bh-slides
https://twitter.com/tqbf/status/376710977669984256

Cheers,

Dirkjan

[Dirkjan Ochtman]

[Stefan Arentz]

On Sep 9, 2013, at 11:16 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 09/08/13 03:30, Brian Smith wrote:
>> Please see https://briansmith.org/browser-ciphersuites-01.html
>

> This proposal promotes ECC.
>
> http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
>
> Schneier: "Prefer conventional discrete-log-based systems over
> elliptic-curve systems; the latter have constants that the NSA
> influences when they can."
>
> He elaborates in the comments:
>
> "I no longer trust the constants. I believe the NSA has manipulated them
> through their relationships with industry."
>
> Does that affect your proposal?

Wasn’t he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ?

S.

[Stefan Arentz]

[Kurt Roeckx]

No, he actually said he doesn't trust any ECC, but on the other
hand said that we should probably move to at least 500 bit ECC.


Kurt

[Rob Stradling]

Probably worth keeping an eye on this new draft and the related
discussion on the TLS list...

http://tools.ietf.org/html/draft-sheffer-tls-bcp-00

--
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.

[Rob Stradling]

The NSA recommends ECC for encrypting secret and top secret information.
So if the NSA have backdoored the NIST curves somehow, presumably
they're 100% confident that the details of the backdoor won't get leaked
or discovered by external researchers!

[Kurt Roeckx]

On Mon, Sep 09, 2013 at 07:20:57PM +0100, Rob Stradling wrote:
> Probably worth keeping an eye on this new draft and the related
> discussion on the TLS list...
>
> http://tools.ietf.org/html/draft-sheffer-tls-bcp-00

Note that the recommended cipher there isn't in Brian's proposal,
and I've already pointed that out.


Kurt