[Ach] Proposal to change B cipher spec

[Aaron Zauner]

Torsten Gigler wrote:
> Is it still an issue?
> (https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat)
Uhm, yes. It took Apple incredibly long to fix this in Safari (it's has
finally been fixed on Mavericks). But a lot of people still run old
versions of OSX. I see that every day. The same issue basically goes for
other browsers on other operating systems.

> 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?)
There's no way to do that - as far as I know. We've included AES-CBC
only as a fallback option in the very last place.

> 
>     > * 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 ;-) )
With an issue remaining: you can still do a MITM attack and force the
weakest cipher.

> 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./
> /
Please read this excellent blog article by djb:
http://blog.cr.yp.to/20140323-ecdsa.html

Quote:
```
DSA was "invented" by NSA's David Kravitz, according to a patent
application filed secretly in July 1991. It was proposed as a standard
by NIST the next month. NIST didn't admit NSA's role until after a
lawsuit was filed by Computer Professionals for Social Responsibility.
NIST memos state that the "reasons for the selection" of DSA are
summarized in an NSA document; as far as I know, that document is still
classified Top Secret.

NIST received many public objections to DSA. (As NIST put it: "the
number of negative comments was significantly larger than normally
received for a proposed Federal Information Processing Standard".) For
example, here are some of Rivest's comments:

It is my belief that the NIST proposal represents an attempt to install
weak cryptography as a national standard, and that NIST is doing so in
order to please the NSA and federal law enforcement agencies. ... A U.S.
standard, even if weak and flawed, may be widely used overseas, making
NSA's job easier.
Technical topics of the objections included DSA's obviously breakable
260 security level (DSA was limited to 512-bit moduli); the lack of an
accompanying encryption mechanism; DSA's poor performance; DSA's
unnecessary computation of an inverse "each time a message is to be
signed"; and DSA's requirement of a cryptographically strong random
number for each signature (Rivest wrote "the poor user is given enough
rope with which to hang himself"). I'll say more later about the
random-number part.

NIST made one change, namely allowing 1024-bit moduli, and then issued
DSA as a standard in 1994. Later NIST extended the standard to ECDSA,
allowing 15 different elliptic curves that had been chosen by Jerry
Solinas at NSA.
```

The article goes on to bash the curves chosen by NSA for their poor
secuity and performance at a time when better options were widely
available. I'm not a EC mathematician, I can only judge from what I
understand about the application of elliptic curves in cryptography.
There seem to be far better options, almost none of them are deployed in
any crypto libraries as of today.

> 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?
Oh god please don't ever :)

>>> 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
So OWASP is actually a pen testing project. Why would you suggest that
not upgrading from XP (out of support in a couple of days) or Win 2003
is even an option? You're not a browser vendor that has to deal with
complaints if it does not work on ancient operating systems.


Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20140404/6089476b/attachment.sig>