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

2013-11-20 Thread Brian Smith
On Tue, Nov 19, 2013 at 9:14 AM, Kurt Roeckx k...@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.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-11-19 Thread Kurt Roeckx
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.

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

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


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

2013-11-18 Thread Brian Smith
On Sun, Nov 10, 2013 at 4:39 AM, Kurt Roeckx k...@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.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-11-01 Thread 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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-10-07 Thread Brian Smith
Mountie Lee moun...@paygate.net wrote:
 SEED was adopted to encourage escaping ActiveX dependency in Korea
 e-commerce environment.

Many people at Mozilla, including us platform engineers, want this
too. Our goal is to get rid of plugins on the internet completely.
And, also, personally I think it is a great idea for Mozilla to do
more to get Firefox working in South Korea. So, I think we all agree
on the goals.

 at last year, adding SEED to WebCrypto API adopted as Action Item.
 the editor sent question any user agent plan to implement SEED

 I can not say discussing terminating SEED support in mozilla

Whether SEED gets implemented to the WebCrypto API is a separate issue
from whether we continue to support SEED in TLS. If we want to add
SEED support to WebCrypto then we can do that even if we don't have
SEED in TLS. I am not going to promise that we will implement SEED as
part of the WebCrypto effort, but I do promise to give it serious
consideration.

 minor algorithm itself has the meaning.
 it will be helpful for neutralizing or keeping possibilities.

I agree that this is a concern. This is one of the reasons we are
looking into the Salsa/ChaCha algorithms, as a backup or replacement
for AES.

Finally, software vendors, including Mozilla, need to work with the
Korean government to agree on what to do about the Korean crypto
regulations. Mozilla has been supporting SEED for TLS for a long time
and it seems to have had no positive impact. If in the future the
software industry and the Korean government decide that SEED in TLS is
the way forward, then we can add SEED back if we remove it now.
However, I am skeptical that the software industry is going to agree
that SEED in TLS is the right path forward.

Cheers,
Brian
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-10-07 Thread 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

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


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

2013-10-07 Thread 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.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-10-07 Thread 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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-10-07 Thread Mountie Lee
Hi.
thanks for mail.

the reason why SEED support give not so much impact is

SEED is not used alone but used with other crypto algorithms (hash,
asymmetric...)

SHA2 hash required in e-commerce transaction by the korean regulation.
and which is also used in TLSv1.1+.

SEED can be used under TLSv1.1+ environment.
as we know, it is just now opened from box.

regards
mountie.


On Tue, Oct 8, 2013 at 3:56 AM, Brian Smith br...@briansmith.org wrote:

 Mountie Lee moun...@paygate.net wrote:
  SEED was adopted to encourage escaping ActiveX dependency in Korea
  e-commerce environment.

 Many people at Mozilla, including us platform engineers, want this
 too. Our goal is to get rid of plugins on the internet completely.
 And, also, personally I think it is a great idea for Mozilla to do
 more to get Firefox working in South Korea. So, I think we all agree
 on the goals.

  at last year, adding SEED to WebCrypto API adopted as Action Item.
  the editor sent question any user agent plan to implement SEED
 
  I can not say discussing terminating SEED support in mozilla

 Whether SEED gets implemented to the WebCrypto API is a separate issue
 from whether we continue to support SEED in TLS. If we want to add
 SEED support to WebCrypto then we can do that even if we don't have
 SEED in TLS. I am not going to promise that we will implement SEED as
 part of the WebCrypto effort, but I do promise to give it serious
 consideration.

  minor algorithm itself has the meaning.
  it will be helpful for neutralizing or keeping possibilities.

 I agree that this is a concern. This is one of the reasons we are
 looking into the Salsa/ChaCha algorithms, as a backup or replacement
 for AES.

 Finally, software vendors, including Mozilla, need to work with the
 Korean government to agree on what to do about the Korean crypto
 regulations. Mozilla has been supporting SEED for TLS for a long time
 and it seems to have had no positive impact. If in the future the
 software industry and the Korean government decide that SEED in TLS is
 the way forward, then we can add SEED back if we remove it now.
 However, I am skeptical that the software industry is going to agree
 that SEED in TLS is the right path forward.

 Cheers,
 Brian




-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : moun...@paygate.net

===
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-10-07 Thread Brian Smith
On Mon, Oct 7, 2013 at 6:05 PM, Mountie Lee moun...@paygate.net wrote:
 SHA2 hash required in e-commerce transaction by the korean regulation.
 and which is also used in TLSv1.1+.

Hi,

First, we will be enabling TLS 1.2 in Firefox very soon.

But, I think you may be referring to SHA-2-based cipher suites
proposed in this internet draft:
http://tools.ietf.org/html/draft-bjhan-tls-seed-00

Unfortunately, that internet draft expired and also the draft didn't
even specify the cipher suite code points.

Where can I find the current version of the Korean regulations on
encryption. I have read this article:
http://www.koreatimes.co.kr/www/news/biz/2012/04/123_109059.html

That article notes that SEED is actually not mandatory in Korea any
more. If so, it seems like a good idea to help the Korean community
standardize on more common algorithms, right?

That article also notes that implementations other than the ActiveX
control have to be certified by the Korean government in order to be
used. So, it seems like our SEED implementation could not be used
legally anyway, since it hasn't been certified. Is that your
understanding?

My understanding is that the Korean government would also require
websites that fall under these regulations to use certificates issued
by some Korean certificate authorities. But, Mozilla does include
either of the Korean certificate authorities and it seems unlikely to
happen soon. See https://bugzilla.mozilla.org/show_bug.cgi?id=335197

Finally, the SEED cipher suite we do currently support does not
support ephemeral key exchange. I see that the internet draft I linked
to above does attempt to specify SEED cipher suites that support
ephemeral key exchange.

So, it seems pretty clear to me that it is OK to disable the SEED
cipher suite we have currently enabled for now, while we figure out
all the things that are necessary to help our Korean users.

Cheers,
Brian
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-10-02 Thread Mountie Lee
Hi.
let me add my comment for SEED.

SEED was adopted to encourage escaping ActiveX dependency in Korea
e-commerce environment.

the impact of mozilla's effort was not figured out well.
but it has meaning and VERY helpful for us to expand web standard
environment (plugin free)

at last year, adding SEED to WebCrypto API adopted as Action Item.
the editor sent question any user agent plan to implement SEED

I can not say discussing terminating SEED support in mozilla

minor algorithm itself has the meaning.
it will be helpful for neutralizing or keeping possibilities.

terminating SEED support in mozilla will give very bad impact.
it will escalate the impact to other good but minor algorithms or web
standard industries.

I hope mozilla member understand my comment successfully.

regards
mountie.



On Fri, Aug 9, 2013 at 11:30 AM, 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-tech-crypto@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-tech-crypto




-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : moun...@paygate.net

===
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-10-02 Thread Mountie Lee
let me add one more.
SEED is normally used for TLS 1.1+ because the SSL Certificate issued from
Korean CA use SHA2 hash algorithm.
browser support for TLS 1.1 is limited currently.
I expect that is one of the reasons why Korean web servers are not add SEED
Cipher suites in SSL configuration.

regards
mountie.



On Wed, Oct 2, 2013 at 6:15 PM, Mountie Lee moun...@paygate.net wrote:

 Hi.
 let me add my comment for SEED.

 SEED was adopted to encourage escaping ActiveX dependency in Korea
 e-commerce environment.

 the impact of mozilla's effort was not figured out well.
 but it has meaning and VERY helpful for us to expand web standard
 environment (plugin free)

 at last year, adding SEED to WebCrypto API adopted as Action Item.
 the editor sent question any user agent plan to implement SEED

 I can not say discussing terminating SEED support in mozilla

 minor algorithm itself has the meaning.
 it will be helpful for neutralizing or keeping possibilities.

 terminating SEED support in mozilla will give very bad impact.
 it will escalate the impact to other good but minor algorithms or web
 standard industries.

 I hope mozilla member understand my comment successfully.

 regards
 mountie.



 On Fri, Aug 9, 2013 at 11:30 AM, 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-tech-crypto@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-tech-crypto




 --
 Mountie Lee

 PayGate
 CTO, CISSP
 Tel : +82 2 2140 2700
 E-Mail : moun...@paygate.net




-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : moun...@paygate.net

===
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-10-02 Thread f0955899688

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


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

2013-09-13 Thread 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.

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online

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


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

2013-09-13 Thread 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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-09-12 Thread 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 | 2.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) 

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

2013-09-12 Thread 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


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


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

2013-09-12 Thread Julien Vehent

On 2013-09-12 22:01, Julien Pierre wrote:

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.


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.



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


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


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

2013-09-12 Thread Stefan Arentz
How about mobile?

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

 S.

- Original Message -
From: Julien Vehent jul...@linuxwall.info
To: Julien Pierre julien.pie...@oracle.com
Cc: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org
Sent: Thursday, September 12, 2013 10:35:06 PM
Subject: Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On 2013-09-12 22:01, Julien Pierre wrote:
 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.

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.


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


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


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

2013-09-12 Thread 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

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


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

2013-09-10 Thread 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

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


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

2013-09-09 Thread hsivonen
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.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-09-09 Thread Alan Braggins

On 22/08/13 11:50, Alan Braggins wrote:

On 21/08/13 18:23, Zack Weinberg wrote:

 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


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.

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


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

2013-09-09 Thread 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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-09-09 Thread Dirkjan Ochtman
On Mon, Sep 9, 2013 at 5:16 PM, Gervase Markham g...@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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-09-09 Thread Stefan Arentz

On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@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.

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


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

2013-09-09 Thread Kurt Roeckx
On Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote:
 
 On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@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 
 ?

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

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


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

2013-09-09 Thread 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!


On 09/09/13 17:15, Kurt Roeckx wrote:

On Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote:


On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@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 ?


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
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-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-09-09 Thread 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

On 09/09/13 17:15, Kurt Roeckx wrote:

On Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote:


On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@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 ?


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
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-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-29 Thread Kurt Roeckx
So what needs to happen so that we can move on with this?


Kurt

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


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

2013-08-26 Thread Brian Smith
On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea rrel...@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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-26 Thread 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.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-26 Thread Robert Relyea
On 08/26/2013 02:24 PM, Brian Smith wrote:
 On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea rrel...@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.

So at this point I want to point out that:

1) I don't disagree with PFS before the other ciphers, I just wanted to
point out that they are not clearly as big a win for security as is
normally touted.
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.


 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.
So as I pointed out, we should list performance measurements as to the
difference in cost. If you can see the difference, simply include those
numbers.
  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.
My bad, I missed that point. Sorry.
 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 is argument does have teeth, probably more than the performance
(depending on the actual performance).

When using performance as a criteria at all, it should be quantified.
For clients 3x slower doesn't mean anything if it's 3x 100 microseconds,
but if its 3x 1s it makes a big difference. We should measure both on
big platforms and small ones.

So in summary. 128 is actually considered as secure as 256 (based on
recent attacks) or better (based on timing attacks), so performance
isn't the primary criteria.

If we were to shop this list around to other browsers, it would probably
be good to get the performance numbers. Particularly ECDHE 256 versus
RSA 2048 on an arm (If that doesn't show a significant cost, we can
safely say performance of the key exchange is negligible).

bob








smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

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

2013-08-26 Thread 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

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


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

2013-08-23 Thread 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

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


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

2013-08-23 Thread Robert Relyea
On 08/23/2013 02:03 AM, Gervase Markham wrote:
 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.
This has the same characteristics as 1. Once in the server, it's more
likely the attacker will fetch the data at rest than try to decrypt
recorded SSL connection.  Once the private key is pinched, future
connections are vulnerable even if they are PFS.

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

Most ways the server could sabotage the connection are detectable to the
client. I'm also pointing out that PFS is not a panacea. It's often
touted as such, but it's relatively easy to defeat.

To be clear, I'm not against PFS, and I don't disagree that it should be
placed forward, what I am pointing out is that any argument based on
performance to put 128 over 256 is completely ignoring the fact that PFS
is at least 3 times as expensive as the equivalent non-PFS algorithms
for only marginal theoretic security enhancement.

I think we need to be consistent in our choices here (of course as a
security guy, I'm quite happy with security over performance as the
default).

bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

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

2013-08-22 Thread 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?

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


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

2013-08-22 Thread Robert Relyea
On 08/19/2013 11:06 AM, Kurt Roeckx wrote:
 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.
It's not that simple. Which individual algorithm is faster is often
platform and key size dependent. The traditional ordering has been
security first, then performance among equivalent. Things like Camellia
and SEED were placed high assuming that server support for them would be
rare, so the would be negotiated on those servers that needed them.

 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.

So, to be clear about ECDHE and DHE, the server *CAN* provide perfect
forward secrecy, but it doesn't have to. The ephemeral key could
simple be another permanent key (or one of several thousands). It's
important to note that a properly implemented DHE/ECDHE is 3 times
slower than DH or ECDH (The latter does a signature, key gen, and key
derive (each doing one group operation), the former simply does a
derive). This cost is born by the server.

 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.

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 128ECC 256   RSA 2048
Symmetric 192ECC 384   RSA 4096
Symmetric 256ECC 512* RSA 8K  (The actual prime
ECC curve is 521 simply because 2^521-1 is prime)

ECC is faster than RSA at low key sizes on restricted hardware (once ECC
is optimized, that is). On faster hardware RSA holds it's own into the
2K range.

to double your security, RSA needs to go up about 4x. Also doubling your
key size increase the cost to do the RSA operation by 4x. ECC is linear
in both cases. So if RSA is 16x faster than RSA at one strength level,
doubling it would make them equivalent.

The upshot is that ECC will always eventually win the performance race
at the top end, but for any given hardware and key strength, RSA may
actually be faster.


 I'm not sure which of RSA and DSA is better, but clearly people use
 RSA more.
DSA is signature only, so it's DHE/DSA versus DHE/RSA versus RSA. Both
algorithms are have different speed characteristics. In RSA signing is
more expensive verification, but still cheaper than DSA signing (unless
you precalculate several k/r/k^-1 values, which hardware may do, but
most software does not bother with). For verification RSA is
significantly faster (why, you may ask, since the math for both is
exactly the same:  S =H^priv mod N, H = S^pub mod N? It's because we can
choose the value of the public key and greatly reduce our work to
calculate X^pub mod N). DSA verification is actually slower than DSA
signing, involving 2 group operations (modular exp in the case of DSA),
and invert and 3 multiplies.

Of core RSA is much faster than any of the DHE/DSA, DHE/RSA for both the
client and the server. It's also faster than DH_ for the same key sizes
(RSA private key ops can use the Chinese remainder theorem to reduce
it's work by 4x, verses DH of the same key size).

 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.
Again, GCM is not necessarily faster than CBC, though GCM doesn't have
to do the hash. Certainly on a 64 bit intel machines with hardware
assist, it's likely to be. GCM isn't vunerable to BEAST attacks.

 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 

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

2013-08-22 Thread Robert Relyea
On 08/16/2013 03:05 PM, Wan-Teh Chang wrote:
 On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco cvie...@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 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).
 Camilo, I think you reverse-engineered Brian's criteria correctly.

 The new criteria seem fine. I would prefer ECDSA over RSA for authentication.
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.

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.

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.

If we are making performance tradeoffs, we really should measure the
real cost rather than just randomly say one is too expensive.
 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.
Agreed SHA256 HMAC, like PFS, is really marketing. SHA1 is weak right
now for signatures because of collision, but HMAC depends on pre-image
resistance, which even MD-5 is still strong against.

At some point marketing wins, as well as the security principle attacks
only get better. As Brian points out, however, AEAD cipher suites solve
both problems.


bob

 Wan-Teh




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

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

2013-08-22 Thread 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 128ECC 256   RSA 2048
 Symmetric 192ECC 384   RSA 4096
 Symmetric 256ECC 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

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


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

2013-08-21 Thread 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.)

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


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

2013-08-21 Thread 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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-21 Thread Zack Weinberg

On 2013-08-20 2:33 PM, Tom Ritter wrote:

On 20 August 2013 14:26, Gervase Markham g...@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


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


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


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

2013-08-20 Thread 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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-20 Thread 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

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


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

2013-08-20 Thread 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

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


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

2013-08-20 Thread Tom Ritter
On 20 August 2013 14:26, Gervase Markham g...@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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-18 Thread Brian Smith
On Thu, Aug 15, 2013 at 10:15 AM, Chris Richardson ch...@randomnonce.orgwrote:

 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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-18 Thread Brian Smith
On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco cvie...@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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-18 Thread Brian Smith
On Fri, Aug 16, 2013 at 5:58 PM, Wan-Teh Chang w...@google.com wrote:

 On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling rob.stradl...@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.


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.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-18 Thread Brian Smith
On Mon, Aug 12, 2013 at 6:52 AM, Gervase Markham g...@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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-16 Thread 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-tech-crypto@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-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-16 Thread 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


  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-tech-crypto@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-tech-crypto@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-tech-crypto



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


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

2013-08-16 Thread 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.


[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-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto



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


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

2013-08-16 Thread Camilo Viecco

On 8/16/13 11:13 AM, Camilo Viecco 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 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. (

And by ECDH I meant ECDHE


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.


[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-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto





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


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

2013-08-16 Thread Wan-Teh Chang
On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco cvie...@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 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).

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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-16 Thread 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-tech-crypto@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-tech-crypto@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-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-16 Thread 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

--
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-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-16 Thread Wan-Teh Chang
On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling rob.stradl...@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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

2013-08-15 Thread 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-tech-crypto@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-tech-crypto

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


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

2013-08-14 Thread Robert Relyea

On 08/09/2013 10:12 AM, Brian Smith wrote:

On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham g...@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.


Minor tweak. The design point has nothing to do with crypto modules. It 
had to do with analyzing combinations of algorithms. In 1994/5 when 
SSL-3 was being designed there were 2 camps: 1) select 
Asymmetric/Symmetric/Macing algorithms separately and 2) cipher suites. 
The security argument fell to cipher suites under the theory that it 
simplified your analysis of whether the algorithm is secure or not. At 
the time no one was thinking of doing operations in tokens, even at this 
point in time, I know of no crypto modules that actually implement 
cipher suites as a suite.



That info is really only of historical interest and doesn't affect the 
rest of Brian's argument (particularly since he's correct in the only 
part of the paragraph Gerv cares about --- that SSL uses suites, not 
arbitrarily mixed combinations of algorithms).




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

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

2013-08-12 Thread 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

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


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

2013-08-09 Thread 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

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


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

2013-08-09 Thread Brian Smith
On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham g...@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
880543https://bugzilla.mozilla.org/show_bug.cgi?id=880543tracks 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

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

2013-08-09 Thread 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: Hmm.

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.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Proposal to Change the Default TLS Ciphersuites Offered by Browsers

2013-08-08 Thread 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)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto