RE: wosign and letsencrypt.cn / letsencrypt.com.cn

[Richard Wang]

In this case, no any CA named as letsencrypt similar name, and no any CA want
to impersonate, most CA program require the root CA have a unique friendly
name in the CA program.


Best Regards,

Richard

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On
Behalf Of Tom Delmas
Sent: Thursday, December 22, 2016 10:30 PM
To: Gervase Markham 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: wosign and letsencrypt.cn / letsencrypt.com.cn

Hi Gerv,

> It's never come up. But I think we would be reluctant to intervene;
Thank you for that answer. I understand it.

> there are other mechanisms for sorting out such disputes, and it's not
> our job to interpret or enforce trademark law or domain name dispute
> resolution law.

There are other mechanisms. But hard to use, especially between countries. As
a Firefox user, I expect that CA trusted by Firefox are clearly identifiable
and distinguishable from each others.

We need CA to avoid website impersonation. In order to achieve that, I feel
that "CA impersonation" must be avoided before all.

And the logical way to do it in my opinion is in the Mozilla CA Certificate
Policy.

Tom
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[Eric Rescorla]

On Wed, Dec 21, 2016 at 11:58 PM,  wrote:

> Hi all,
>
> I already have reported the following issue in the bug tracking system and
> now have been told that the bug has been closed and that I should put it
> for discussion here.
>
> Please note that I am no way a security expert, so please don't blame me
> if the following is wrong. But I am sort of a technical person and
> eventually have understood the key points when it comes to SSL / TLS. So
> here we go:
>
> I have read several articles and white papers about what SSL / TLS ciphers
> are considered secure by cryptography experts. A short summary:
>
> 1) To enable forward secrecy, the key exchange should be done via
> "ephemeral" methods (those with "E" at the end of their names, e.g. DHE or
> ECDHE).
>
> 2) AES in GCM mode should be used as payload encryption method.
>
> 3) Elliptic curves should NOT be used, at least not the curves from NIST,
> because they are suspected (some even say: known) to be poisoned
> intentionally by several sorts of mechanisms. This means that that all
> ECDHE... ciphers are out of the game.
>

I don't believe that this claim reflects the consensus of the security
community.

In any case, as Kurt Roeckx observes, Firefox currently supports the new
non-NIST CFRG curves.

-Ekr

4) SHA256 or higher is considered safe enough to be used as hashing /
> digest method.
>
> Firefox does not offer a single cipher which fulfills all of these
> criteria.
>
> Steps to reproduce:
>
> In Firefox, open "about:config". Type "SSL3" into the search box to view
> the list of available SSL / TLS ciphers.
>
> Actual result:
>
> There is no cipher which fulfills all of the criteria mentioned above.
> Notably, all ciphers which use AES-GCM also use the contaminated ECDHE for
> key exchange; there is no cipher which offers AES-GCM and the secure DHE
> key exchange.
>
> Expected / desired result:
>
> There should at least be one cipher in the list which fulfills the
> criteria mentioned above, i.e. something like that:
>
> security.ssl3.dhe_rsa_aes_256_gcm_sha384
>
> (note the dhe ... instead of ecdhe ...).
>
> Personally, I am considering that as a very serious security problem. The
> fact that other browsers might have the same problem does not change
> anything about that.
>
> I hereby propose that Mozilla enables at least one cipher like
> dhe_rsa_aes_256_gcm_sha384 as fast as possible.
>
> Regards,
>
> Binarus
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: wosign and letsencrypt.cn / letsencrypt.com.cn

[Tom Delmas]

Hi Gerv,

> It's never come up. But I think we would be reluctant to intervene;
Thank you for that answer. I understand it.

> there are other mechanisms for sorting out such disputes, and it's not
> our job to interpret or enforce trademark law or domain name dispute
> resolution law.

There are other mechanisms. But hard to use, especially between
countries. As a Firefox user,
I expect that CA trusted by Firefox are clearly identifiable and
distinguishable from each others.

We need CA to avoid website impersonation. In order to achieve that, I
feel that "CA impersonation" must be avoided before all.

And the logical way to do it in my opinion is in the Mozilla CA
Certificate Policy.

Tom
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[Kurt Roeckx]

On 2016-12-22 08:58, i...@binarus.de wrote:

Hi all,

I already have reported the following issue in the bug tracking system and now 
have been told that the bug has been closed and that I should put it for 
discussion here.

Please note that I am no way a security expert, so please don't blame me if the 
following is wrong. But I am sort of a technical person and eventually have 
understood the key points when it comes to SSL / TLS. So here we go:

I have read several articles and white papers about what SSL / TLS ciphers are 
considered secure by cryptography experts. A short summary:

1) To enable forward secrecy, the key exchange should be done via "ephemeral" methods 
(those with "E" at the end of their names, e.g. DHE or ECDHE).

2) AES in GCM mode should be used as payload encryption method.

3) Elliptic curves should NOT be used, at least not the curves from NIST, 
because they are suspected (some even say: known) to be poisoned intentionally 
by several sorts of mechanisms. This means that that all ECDHE... ciphers are 
out of the game.


The elliptic curves can be used for both the authentication and the key 
exchange. For the authentication it would be the difference between RSA 
and ECDSA.


For the key exchange there are options like X25519 and X448. As far as I 
know, there is nothing suspicious about them. Firefox offers X25519 as 
the first curve.


For the authentication there will be Ed25519 and Ed448 in the future.

Disabling ECDSA support is something you might want to do, but you would 
then be unable to talk to people using only an ECDSA certificate.



4) SHA256 or higher is considered safe enough to be used as hashing / digest 
method.


The are different hashes being used, and depending on the use it might 
have different requirements. SHA1 might be safe to use for some of them.


Anyway, for TLS 1.3 firefox currently offers the following ciphers in 
the following order:

- AES_128_GCM_SHA256
- CHACHA20_POLY1305
- AES_256_GCM_SHA384

Some of the other properties are not part of the cipher anymore, but I 
believe it's possible to have everything you want.


For the TLS 1.2 ciphers it offers, it has them in this order:
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[...]

It does offer ciphers that support all your requirements by default. It 
will just depend on the server if it's going to use X25519 or not. And 
server support for that will currently be very low.



> There should at least be one cipher in the list which fulfills the 
criteria mentioned above, i.e. something like that:

>
> security.ssl3.dhe_rsa_aes_256_gcm_sha384

That, or you need to disable the ECDSA and nist curves for the key 
exchange instead.



Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: wosign and letsencrypt.cn / letsencrypt.com.cn

[Gervase Markham]

On 21/12/16 12:42, tdel...@gmail.com wrote:
> I think Mozilla still doesn't answer my first question:what is the
> position of Mozilla regarding CA that act in bad faith regarding the
> usage of the names associated with others CA (like, registering such
> trademarks or domains) ?

It's never come up. But I think we would be reluctant to intervene;
there are other mechanisms for sorting out such disputes, and it's not
our job to interpret or enforce trademark law or domain name dispute
resolution law.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[info]

Hi all,

I already have reported the following issue in the bug tracking system and now 
have been told that the bug has been closed and that I should put it for 
discussion here.

Please note that I am no way a security expert, so please don't blame me if the 
following is wrong. But I am sort of a technical person and eventually have 
understood the key points when it comes to SSL / TLS. So here we go:

I have read several articles and white papers about what SSL / TLS ciphers are 
considered secure by cryptography experts. A short summary:

1) To enable forward secrecy, the key exchange should be done via "ephemeral" 
methods (those with "E" at the end of their names, e.g. DHE or ECDHE).

2) AES in GCM mode should be used as payload encryption method.

3) Elliptic curves should NOT be used, at least not the curves from NIST, 
because they are suspected (some even say: known) to be poisoned intentionally 
by several sorts of mechanisms. This means that that all ECDHE... ciphers are 
out of the game.

4) SHA256 or higher is considered safe enough to be used as hashing / digest 
method.

Firefox does not offer a single cipher which fulfills all of these criteria.

Steps to reproduce:

In Firefox, open "about:config". Type "SSL3" into the search box to view the 
list of available SSL / TLS ciphers.

Actual result:

There is no cipher which fulfills all of the criteria mentioned above. Notably, 
all ciphers which use AES-GCM also use the contaminated ECDHE for key exchange; 
there is no cipher which offers AES-GCM and the secure DHE key exchange.

Expected / desired result:

There should at least be one cipher in the list which fulfills the criteria 
mentioned above, i.e. something like that:

security.ssl3.dhe_rsa_aes_256_gcm_sha384

(note the dhe ... instead of ecdhe ...).

Personally, I am considering that as a very serious security problem. The fact 
that other browsers might have the same problem does not change anything about 
that.

I hereby propose that Mozilla enables at least one cipher like 
dhe_rsa_aes_256_gcm_sha384 as fast as possible.

Regards,

Binarus
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy