Re: [TLS] Unifying tickets and sessions

[Richard Fussenegger <[e-mail]>]

I noticed that you all try to dictate your believes of security to 
others, which is actually very interesting to read so please don't stop 
(there's **really** no sarcasm in this sentence, but maybe you should 
rename the thread then because this discussion is otherwise not going 
anywhere). But you just mentioned a *very* important thing: 128-bit are 
sufficient today for generic web applications.

Do we want a fully encrypted web? **Yes!**
When do we want it? **Now!**

The essence of my previous message (partly quoted below) was, that it is 
important to ensure within the RFC that a ticket that is storing the 
state of a SUPER-CRYPTO-9999 cipher isn't going to be encrypted with a 
GENERIC-CIPHER-128 key. This would simply downgrade the security of the 
whole agreed upon cipher. But on the other hand if an administrator 
decided that his web service is only delivering cat photos and that 
GENERIC-CRYPTO-128 is sufficient in terms of computing power for his 
server and for his clients, than it doesn't make sense to encrypt the 
ticket with SUPER-CRYPTO-9999.

Of course if the same administrator decided to support both, 
GENERIC-CRYPTO-128 and SUPER-CRYPTO-9999, then he'll require the 
SUPER-CRYPTO-9999 for all tickets. Viktor Dukhovni already mentioned 
that OpenSSL is actually supporting different key strengths, but for 
instance nginx isn't exposing this setting to administrators. But the 
RFC would most certainly compel them to do so in the future, which is a 
good thing. After all, the cat-photo-admin may continue to use fast and 
insecure ciphers (but still protecting clients and his services from 
script kiddies) and the nice whistleblower from our neighborhood may use 
the best available cipher available.

Rich Salz said that the RFC should stay silent on which crypto to use 
and I agree for above reasons and everything you guys brought up. 
Stating that crypto-X is sufficiently secure is like saying that god is 
for real; maybe it is true but science and research will eventually 
prove the opposite in the future. I stated that (the former not the 
latter, I'd never say such a thing) and made a mistake by doing so. But 
I hope that this message clarifies my intentions and also that some of 
you have an opinion about the actual proposal of mine.

Regards
Richard

On 10/22/2014 6:44 PM, Ryan Carboni wrote:
>
> From: "Richard Fussenegger, BSc"
>
>     [*] Better would be 'from all ciphers in use' otherwise one ends
>     up with
>     a (insert ridiculous high value here) bit key while only using 128 bit
>     ciphers in the configuration. Dropping the key if a new stronger
>     configuration is loaded seems like a good idea to me at this
>     point. I'm
>     looking at this from a performance perspective and glimpsing over
>     to the
>     fact that the cryptography community agrees that 128 bit security will
>     be enough for the next 10 to 20 years.[2] I really can't tell if this
>     would be problematic from an implementation point of view. I think
>     that
>     single hosts won't have a problem here and I guess that it wouldn't be
>     for clusters as well. The cluster configuration should be in sync
>     but it
>     could become a problem if one node has a differing configuration (for
>     whatever reason). What opinion/insights do you have on this?
>
>
>  Quantum computers are reaching 512-qubits now. 
> http://www.bbc.com/news/science-environment-27632140
>
> Quantum cryptography would result in key-sizes effectively being 
> halved, and in 15 to 40 years a quantum computer could potentially be 
> built by a nationstate to enhance known cryptographic attacks and 
> reduce keyspaces substantially.
>
> It's unlikely though that the NSA will devote quantum computing to 
> breaking the encryption of cat videos.
>
> I suggest an advisory that for unauthenticated encryption, 128-bits 
> are used, and for authenticated encryption 256-bits or more are used. 
> The only issue is that browsers tell you the whole page is encrypted 
> the same way even though elements of the page use different sorts of 
> encryption than the body of the page.
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls