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

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

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

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

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

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

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

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

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

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

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,

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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:

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

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

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:

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

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

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?

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

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

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

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

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

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

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

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