[Ach] Proposal to change B cipher spec

[ianG]

On 4/04/2014 01:37 am, Aaron Zauner wrote:

>> * Append the list with Ciphers for legacy browsers and web crawlers
>> * Do not use RC4, MD5,... etc
>> * Ciphers should be usable for DH >= 2000 bits, without blocking latency
>> browsers
>>
>> Conrete this results in this ciphers (grouped according above policy):
>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
> Basically you'll need SHA512 to fit the security level of AES256. We
> have this issue as well. No SHA512 in TLS :)


Wait - in the role above, SHA is used as a HMAC, right?  If that's the
case (I haven't looked at the protocol) then SHA is overkill, you don't
need to match the full 256 bit collision strength against AES256 because
the attacker only has max a few seconds to try and break the HMAC, which
also ... is a keyed MAC.

This stands in contrast to something like a SHA1 sig in a sub-root cert,
which might be cracked over the next few years if someone puts a mining
rig to the task.

(Or have I missed something...)


>> 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)
> SHA-1: 160bit. You'll need a cryptographic hash function of 512 bit to
> match the security of the symmetric cipher (AES). As well as appropriate
> RSA/DH params.


Ditto.

>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
>> =================================================
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
> See above.
> 
>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
> DSA is a bad standard, as is DSS. ECDSA seems to be even more broken:
> http://blog.cr.yp.to/20140323-ecdsa.html


All your DSA belong to us.


iang