[Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Aaron Zauner]

Hi Julien,

On 02 Jan 2014, at 23:06, Julien Vehent <julien at linuxwall.info> wrote:

> 
> 2. My experience as a web hosting engineer, and sysadmin, has convinced me that
>   building security recommendations on what academia thinks alone is very dangerous.
>   Security doesn't live in a bubble. It depends on people and systems. It must
>   protect an activity, but never ever block it entirely.
I’ve also been working as a systems engineer and developer for more than 6 years now and did a lot of FOSS related stuff before that.
I do not think that is true. Usually there is a finding in academia that people exploit a short afterwards. Yes it’s pratical. Look at CRIME
and padding-oracle attacks in general for an example of TLS insecurity that resulted of research (and recommendations) by academia.

> Others at Mozilla, Google and major organizations have decided
> to implement ECC, and we trust their decision.
The findings by Bernstein et at. are relatively new. I do expect people to react sooner or later.  I also expect there to be a lot of new 
research and possibly real-life TLS security implications. But I might be wrong.

> Aside from performance, timing attacks are apparently easier in AES-256.
> https://groups.google.com/forum/#!msg/mozilla.dev.tech.crypto/36na1B2brGU/xUMMPMgkmEMJ
Thanks, we’ll make sure to include this to the paper. I have no problem with AES-128, personally that is what I would have chosen, 
the overhead of AES256 is just to much for e.g. hosting environments or large traffic websites. I’ve also remarked upon this a couple
of times. But the decision is not mine alone to make.

> 3DES isn't broken.
Triple DES provides about 112bit security (We’ve a section on the topic in the Paper in the Keylenghts section). All ciphers that we
recomend are at least at 128bit security.

See also: http://crypto.stackexchange.com/questions/6345/why-is-triple-des-using-three-different-keys-vulnerable-to-a-meet-in-the-middle

> RC4 is broken, but I am yet to see a practical attack that doesn't require gigabits of traffic.
> Again, this is the tradeoff between what academia thinks is secure, and the level of security
> users need. It's more important for us to allow Chinese users to download Firefox, than it is
> to disable RC4 (that westerners almost never use anyway).
Thats just what one attack suggests, there may be improvements or even better attack vectors.
Recent leaks started discussion in the crypto community about a possible breakthrough by the NSA so that they can exploit RC4 in real 
time. This has only been implied by leaked documents and nothing was yet disclosed that proofs this theory. But when I talk about end-user 
security I might want to consider that NSA has some of the best cryptanalysts and mathematicians at their disposal. And after all they are a 
threat to online security. Microsoft recently labeled the US Govt. as APT. And thats not even the only issue I have with RC4, those findings
regarding TLS have been published in March. There are a lot of attack vectors known for RC4: http://en.wikipedia.org/wiki/RC4#Security
The literature is full of them, I think wikipedia only states a third or so. Even if those are academic publications some may potentially be 
adopted and used on TLS traffic. I just don’t feel safe recommending RC4 to anyone, and I havent felt safe about RC4 in the last years
either. After BREAK there was this huge outcry by “security professionals” to switch to RC4, I still think that was a dumb idea.

> For us, it's a choice between DHE with 1024, or no DHE at all. We will not block a subgroup
> of users because they don't support larger keys. And I suspect no business ever will.
Of course. Our paper is only a recommendation and things that we’d like to see implemented.

> RSA key rotations happen very rarely in hosting environments. Except when the CA requires it,
> it's not uncommon to see private keys that are several years old. Keys also move very easily,
> end up in people's mailboxes or shared folders, or get stored in cloud providers that don't
> zero their disks after use.
Yes. But thats a huge issue. People actually should regenerate their keys frequently. As more traffic is encrypted with one key the easier
it gets to mount different attacks on the server (e.g. chosen ciphertext attacks). The issue you mentioned with Keys being mailed is an
obvious one but we do not provide a guide on OPSEC. Of course that should not happen but it does.

Thanks for your time and feedback,
Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20140103/b7c3fb3c/attachment.sig>