[Ach] Proposal to change B cipher spec

Fri Apr 4 17:18:17 CEST 2014

Hi Aaron, hi Pepi ,

thank you very much for your comments.
<http://dualec.org/DualECTLS.pdf>
I tried to answer to both mails with this mail. I marked Pepi's answer with
'P>'.

Kind regards
Torsten

2014-04-04 2:37 GMT+02:00 Aaron Zauner <azet at azet.org>:

> Hi Torsten,
>
> First off: Why wouldn't the OWASP project simply refer to other projects
> concerning cryptography recommendations (ENISA, bettercrypto [...])?
> This might spare you hours of valuable time.
>
In my project there, we'd like to include the most important best practices
to mitigate the OWASP Top 10. These Examples in our Wiki are used as an
appetizer for the Links (within and outside OWASP). Up to now, we run for
this to support JAVA and PHP developers. Up to now we started it in German.
You have done a great job on bettercrypto.org, so you are naturally
included as Link ;-)

>
> Torsten Gigler wrote:
> > I'd like to contribute this policy for ciphers to the discussion:
> > * Highest Priority for Ciphers that support 'Forward Secrecy'
>
P> ONLY ciphers that support PFS, non-pfs compatibility fallback only for
TLS 1.0.
P>
P> In addition: I propose to change the cipher string to disable
TLS_RSA_WITH_AES_(128|256)_CBC_SHA (0x2f|0x35) for TLS > 1.0. > It is our
"legacy fallback cipher" and shouldn't be used in TLS 1.1 or TLS 1.2 in
favor of PFS ciphers.
This would be fine. Do you know how to configure this with e.g. Apache?

> > * Favor DHE over ECDHE (with a hint to check the performance)
> ACK.
>
P> With proper TLS session tickets the impact of DHE is minimal even on
slow devices like "smart" phones.

>
> > * Favor GCM over CBC regardless of the cipher size
> ACK. CBC mode in TLS <1.1 will be vulnerable to the BEAST attack.
>
> Is it still an issue? (
https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat
)
What do you suggest for this for TLS<1.1, I think RC4 does perhaps more
worse than good (+ same question as above, how to limit cipher to be used
only for old protocols?)

> * Priorize the ciphers by the sizes of the Cipher and the MAC
> How do you prioritize those? The MAC has to fit the security of the
> symmetric algorithm in question.
>
You priorize them by the order of the Cipher String, which defines the
order, if the 'server order' is set.
In this case the* server selects* one of ciphers a* client offers* in the
Client-Hello. So you can control on server side the cipher that will be
used when a type of browser connects (if the user does not suppress some
ciphers ;-) )
E.g. (for the cipher string discussed in this thread):
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) will be used by Opera and
Safari, TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) will be mainly used by
Chrome and Firefox;
https://www.ssllabs.com/ssltest/analyze.html?d=bettercrypto.org&hideResults=on(Handshake
Simulation for the  cipher string of
bettercrypto.org)
Up to now, I do not understand the order of the bettercrypto.org cipher
string (DHE/ECDHE, and GCM/CBC mixed...) .....

> > * Favor RSA over ECDSA
> ACK.
>
P> I'd like to discuss the exclusion of DSA.
P> https://projectbullrun.org/dual-ec/tls.html
P>
P> When you have bad randomness and reuse a nonce you're leaking your
private key. Nadia Heninger called this a "strange property" in "The year
in crypto" at 30C3.
P>
http://media.ccc.de/browse/congress/2013/30C3_-_5339_-_en_-_saal_1_-_201312281830_-_the_year_in_crypto_-_nadia_heninger_-_djb_-_tanja_lange.html

Do you mean this "The researchers also successfully recovered signature
keys from TLS servers that used DSA or ECDSA to sign DH/ECDH public keys."?
(from http://dualec.org/DualECTLS.pdf /
*Cache
<http://www2.futureware.at/~philipp/dualec/On%20the%20Practical%20Exploitability%20of%20Dual%20EC%20in%20TLS%20Implementations.htm>)*
*=> *Yes, it is possible to downgrade or exclude this ciphers even without
loosing a Browser or huge downgrades of cipher strength.

>
> I have recently come to the conclusion that - basically - djb pointed to
> and solved most problems 10years before the wider community and
> implementors notice them. Of course this is a generalization - and not
> always true (TCP SYN cookies) - but it's mostly true. The issue being
> that you need more feedback than djb to standardize stuff. :)
>
> Ed25519 looks really nice. But it's not deployed anywhere near TLS, as
> far as I know. See: https://en.wikipedia.org/wiki/EdDSA
>

related hint (off topic, I know): DNSSEC DDOS will become a real problem
> in the next couple of years. I've talked to Dan Kaminsky on twitter
> about the issue. His basic response was "but other protocols suck as
> well!". Without starting another flame: this is just naive. Have fun
> with a badly designed, hierarchical, "trust" protocol. As such DANE
> seems to be doomed as well.
>
> > * Append the list with Ciphers for legacy browsers and web crawlers
> > * Do not use RC4, MD5,... etc
>
P>Already the case.

 > * Ciphers should be usable for DH >= 2000 bits, without blocking latency
> > browsers
>
P> That is a client and implementation problem. Many clients balk at DH
params > 1024bits.
Agree. But the server should not use DH-Ciphers used by latency browsers
with this issue (=> so I haven't included ciphers like
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32)'), OK?

>> TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
P> We already agreed to NOT include this one.
This is the only cipher I found that is usable for IE on XP, Win 2003

P> Our ciphers also explicitly specify cipher's 256bit and 128 bit variants
so one can easily disable the 128bit variants without having to do a lot of
research on how to properly specify a cipher string. (You can just remove
all -128- parts of the string to end up with only 256bit ciphers. This is
intentional.)

P> Best regards
P> Pepi

> * Append the list with Ciphers for legacy browsers and web crawlers
Our "Cipher A" doesn't respect compatibility with clients at all,
especially not legacy ones. Our "Cipher B" is less forward looking and
wider compatible. I consider it a bad proposal to give way to broad
compatibility in our recommendations. Repeating myself: We're doing
betterCRYPTO.org not bettercompatibility.org or betterperformance.org.
(Both domains _still_ available.)
Well this is always the question between security and usablility, you
should know the risk and decide....
I do think that is easy to get an A+ at ssllabs.com, but you won't be
accessible any more by a huge audience.

> > Conrete this results in this ciphers (grouped according above policy):
>
Updated:

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
-------------------------------------------------
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
=================================================
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
.................................................
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
-------------------------------------------------
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) => probabely excluded
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) => probabely excluded
.................................................
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) => probabely excluded
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)    => probabely excluded
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) => probabely excluded
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)    => probabely excluded
=================================================
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
-------------------------------------------------
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
NN ?     => Any alternative for 'TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)'
for letency browsers/OS like Win 2003/XP?

=> openssl ciphers -V
EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:-DHE-RSA-AES128-SHA:EECDH+aRSA+AESGCM:EECDH+aRSA+AES:RSA+AESGCM:RSA+AES+SHA

(without DAS, 3DES)

> >
> > This could be reached by this cipher string:
> > openssl ciphers -V
> >
> EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:-DHE-RSA-AES128-SHA:EECDH+AESGCM:EECDH+AES:RSA+AESGCM:RSA+AES+SHA:DES-CBC3-SHA
> >
> > Remarks:
> > '-DHE-RSA-AES128-SHA':used to be able to use DH >= 2000 bits, without
> > blocking latency browsers
> > 'DHE-RSA-AES256-SHA': for compatibility reasons for elder versions of
> > openssl
> I don't really follow there, regarding the "DH >= 2000 bits".
>
 I have excluded DH-ciphers that are used by IE and Java that support only
1024bits (os less). If not the cipher may be choosen by the server and fail
on the client later (see also above)

>
>
> Aaron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20140404/2c8eec35/attachment.html>