[Ach] EDH/ECDH, AES128/AES256 - was: Secure E-Mail Transport based on DNSSec/TLSA/DANE

[Terje Elde]

> On 02 Nov 2015, at 21:24, Gunnar Haslinger <gh.bettercrypto at hitco.at> wrote:
> 
> 
>> The reasoning for camellia is AFAIR that it can be used as sane
>> fallback if a flaw in AES is found.
> 
> OK, point taken.
> but i could easily enable it when such a Situation happens, and
> hopefully AES doesn't get broken the next 15+ years, could lead into a
> disaster.

I'm usually in favor of keeping target-audience in mind, when making recommendations. There's often a difference between what I'd recommend to a highly skilled and attentive sysadmin, and what I'd recommend to someone just learning the ropes for example. 

I think this is worthwhile to keep in mind when making general recommendations to the public at large as well. Some will view the recommendations as "flavor of the week", some will deploy it in systems - or even products - that they're likely to never touch again. 

Sure, if AES should get broken, most of us could throw it out of most of our systems. 

But could most people following the recommendations, throw it out of most of the systems they configure today, if an issue is found in 5 years?

Packages might get updated and patched, but as we've seen in the last few years, config that works often doesn't get changed, even when there's issues. 

For systems I know I'll keep a close eye on, I don't currently worry about camellia one way or the other. For systems I might not be responsible for in 5 years, I'd rather leave it in. And I'd prefer the same as a general recommendation to the public at large. 


The argument of low client support certainly is valid, but if you look at things from a 5 year perspective, all of that changes. If there's suspicion of an issue with AES for example, client support can quickly pick up. 

At that point, it'd be nice if server support was available. 

I think it would make a lot more sense to look at cipher-selection not just from a "here and now"-perspective, but rather with a view towards the merits of the ciphers. 

As a side point; It's not that I'm overly worried about AES getting broken in the next 5. It's more that security is hard to predict and that makes it wise to keep options open. A full break of AES in the next 5 probably won't happen, but a break such as key leakage from AESNI-usage? I'm less certain. Such a flaw - at scale - could quickly lead to wanting to temporarily shift traffic over to other algorithms. 

Terje Elde