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

[Michael Sweet <[e-mail]>]

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?

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?


On Sep 17, 2014, at 10:03 PM, Watson Ladd <[e-mail]> wrote:

> On Wed, Sep 17, 2014 at 6:16 PM, Martin Rex <[e-mail]> wrote:
>> Nico Williams wrote:
>>> On Thu, Sep 11, 2014 at 05:18:37PM +0200, Martin Rex wrote:
>>>> I also don't understand why the fact that TLS finished messages are
>>>> encrypted would make any proof harder.  I believe that to be untrue.
>>> 
>>> Hugo K.'s rationale is that you then need to have replay protection.  We
>>> need replay protection anyways, but if you're only analyzing the
>>> handshake then it helps to not have to include subsequent replay
>>> protection in the analysis.
>> 
>> Somehow that argument feels quite lame when it is combined with the
>> argument "the proof would be easier when the finished messages were
>> sent in the clear, could we not change this".
>> 
>> Just do the proof under the assumption/premise that the finished messages
>> *ARE* in the clear.  Then send them encrypted.  Unless you're doing avoidable
>> weird things, sending them encrypted rather then in the clear should not
>> affect the original proof at all.
> 
> Yes, that's what previous analysis had to do. In combination with
> other misfeatures (need for Oracle DH assumptions, additional
> complexity) the result was that protocol weaknesses went undetected.
> 
> The bigger the difference between TLS and the protocol that is
> actually analyzed, the weaker the guaranties are about the safety of
> TLS. Furthermore the space of changes people make to TLS is much
> larger than is actually realized: take all the RFCs referring to any
> version of TLS, and consider that each one may or may not be
> implemented. The resulting combinatorial explosion cannot be dealt
> with except by modularizing the proof.
> 
> TLS 1.3 adds new tricks, like Zero-RTT, one-RTT forms, and possibly
> new forms of encrypted data. The easier it is to analyze the core
> protocol the easier it will be to analyze these proposals, and fix
> them. Most of the people who are making proposals including myself
> have not got the ability or time to do a proper analysis. The few
> people who do are really overworked, and so far we've heard nothing
> from them (for good reason: you don't want a late change to turn a
> significant amount of work into a nonstarter) It is a substantially
> more complicated protocol.
> 
> We need to think about how to avoid the past two decades of major
> cryptographic weaknesses, repeatedly identified in TLS
> implementations, some of which are still not fixed.
> 
> Sincerely,
> Watson Ladd
>> 
>> If the TLS channel would be sensitive to what exact data is transferred
>> within that encrypted channel, then you would have *MUCH* larger problems
>> and it would apply to just about any kind of arbitrary application data.
>> 
>> -Martin
> 
> 
> 
> -- 
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair