On Tue, Nov 19, 2013 at 9:14 AM, Kurt Roeckx 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 wrote:
>> >
>> > Also, AES implementations are highly optimized, well-audited,
>> > well-tested, and are more likely to be side-chan
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 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, so
On Sun, Nov 10, 2013 at 4:39 AM, Kurt Roeckx 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:
On Sat, Nov 09, 2013 at 02:57:48PM -0800, Brian Smith wrote:
> Last week, I also learned that ENISA, a European standards group,
> recommends Camellia alongside AES as a future-proof symmetric cipher
> algorithm; see [4].
They recommend:
- *_AES_*_GCM_*
- *_CAMELLIA_*_GCM_*
- *_AES_*_CCM_*
As I a
On Fri, Nov 1, 2013 at 2:22 AM, Kurt Roeckx wrote:
> On Mon, Oct 07, 2013 at 09:06:54PM +0200, Kurt Roeckx wrote:
>> On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote:
>> > So what needs to happen so that we can move on with this?
>>
>> I still have the same question. Nothing seems to b
On Fri, Nov 01, 2013 at 10:22:22AM +0100, Kurt Roeckx wrote:
> On Mon, Oct 07, 2013 at 09:06:54PM +0200, Kurt Roeckx wrote:
> > On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote:
> > > So what needs to happen so that we can move on with this?
> >
> > I still have the same question. Noth
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 w
On Fri, Nov 1, 2013 at 10:22 AM, Kurt Roeckx wrote:
> So it's been 2 months since the last discussion about this. Can
> we please move on?
His Bugzilla status suggests Brian might have left Mozilla:
"Brian Smith (:briansmith, was :bsm...@mozilla.com; NEEDINFO me if you
want a response)"
So tha
On Mon, Oct 07, 2013 at 09:06:54PM +0200, Kurt Roeckx wrote:
> On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote:
> > So what needs to happen so that we can move on with this?
>
> I still have the same question. Nothing seems to be happening.
So it's been 2 months since the last discus
On Mon, Oct 7, 2013 at 6:05 PM, Mountie Lee 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
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.
On Mon, Oct 7, 2013 at 4:50 PM, Brian Smith wrote:
> On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent
> 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,
>
On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent 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 perform
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
Mountie Lee 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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
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.
regar
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, "addin
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
On 13/09/13 04:52, Julien Pierre wrote:
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 thi
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 her
tember 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 disagr
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
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 a
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 gener
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 alrea
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
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
On Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote:
>
> On Sep 9, 2013, at 11:16 AM, Gervase Markham 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.theguard
On Sep 9, 2013, at 11:16 AM, Gervase Markham 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: "P
On Mon, Sep 9, 2013 at 5:16 PM, Gervase Markham 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 th
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 syst
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
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 skeptic
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
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 E
On 08/26/2013 02:24 PM, Brian Smith wrote:
> On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea 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 (no
On Mon, Aug 26, 2013 at 2:24 PM, Brian Smith 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-
On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea 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
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.
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
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
On 08/16/2013 03:05 PM, Wan-Teh Chang wrote:
> On Fri, Aug 16, 2013 at 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. removin
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 t
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
On 2013-08-20 2:33 PM, Tom Ritter wrote:
On 20 August 2013 14:26, Gervase Markham 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
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
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:
On 20 August 2013 14:26, Gervase Markham 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 i
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.
>
>
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
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 clea
On Mon, Aug 12, 2013 at 6:52 AM, Gervase Markham 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
>
On Fri, Aug 16, 2013 at 5:58 PM, Wan-Teh Chang wrote:
> On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling
> 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
On Fri, Aug 16, 2013 at 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 ciph
On Thu, Aug 15, 2013 at 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 th
On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling 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"
On 16/08/13 23:05, Wan-Teh Chang wrote:
8. Authentication: RSA before ECDSA
a. RSA before ECDSA : performance
b. DSA last: not in use
... 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 we
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 i
On Fri, Aug 16, 2013 at 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 ciphe
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 s
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:
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 A
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 connectio
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 f
On 08/09/2013 10:12 AM, Brian Smith wrote:
On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham 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
eleme
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 d
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
p
On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham 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
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 a
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
71 matches
Mail list logo
