Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof]

[Michael Sweet <[e-mail]>]

Nikos,

The claim was made that TLS + some combination of extensions will produce a non-secure result.  I.e., TLS + Extension Foo is secure, TLS + Extension Bar is secure, but TLS + Foo + Bar is not secure (or cannot be proven to be secure).

Thus, my comment was just a question: if we can't ensure that all combinations of TLS extensions are secure, does it make sense to negotiate sets of extensions instead of the individual extensions?  Obviously a single extension should be secure on its own (otherwise, why is it being approved for use in TLS?), but if a combination of extensions can cause interactions that are not secure then it would make sense to have a way to lock those combinations out (blacklist) or negotiate known good combinations (whitelist).  And having worked with enough security people over the years, I know what the usual preference is for such things (whitelists)...

(I am not a TLS or security expert, just somebody that uses TLS and knows that I don't know everything about it, so I ask questions even if the answers are obvious to those that can claim to be experts...)


On Sep 18, 2014, at 10:24 AM, Nikos Mavrogiannopoulos <[e-mail]> wrote:

> On Thu, 2014-09-18 at 07:29 -0400, Michael Sweet wrote:
>> My $0.02: Would it make sense to stop treating extensions as an a la
>> carte mechanism, and instead define "extension suites", much as TLS
>> already groups specific combinations of cryptographic primitives that
>> can be selected in cipher suites?
> 
> Well, I think we need more than your 2 cents for that. Could you
> elaborate what you mean here? The extensions were put in place to
> overcome the limitation of the ciphersuites that you just mentioned.
> 
>> Seems like that would limit the allowed combinations of extensions to
>> those that have gone through the necessary analysis and are considered
>> "safe" to use together?
> 
> Isn't that the set of all extensions that are published by this working
> group?
> 
> regards,
> Nikos
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair