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

[Watson Ladd <[e-mail]>]

On Wed, Sep 17, 2014 at 8:40 PM, Nico Williams <[e-mail]> wrote:
> On Thu, Sep 18, 2014 at 03:16:22AM +0200, Martin Rex 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.
>
> To me the argument feels lame because we must anyways be able to
> distinguish record types[0] and detect replays[1] (at least for TLS, and
> for DTLS[2] I would argue that replays of handshake messages must always
> be enabled).

That wasn't the argument Mr. Krawczyk and I made. TLS provides a
secure channel, and we know how to prove it does.
Rather the problem is that some applications like RFCs I've cited,
that are deployed, use the TLS handshake to derive a key
that is used for another purpose. This is not safe without analysing
the specifics of the encryption scheme used.

In particular, an application that has its own record layer may
interpret the Finished message in strange ways. This can cause
problems.

There are other unpatched issues, like the possibility to misinterpret
the Server Key Exchange field and use this to impersonate a server,
that need addressing. And so far nothing has been said about the
proposed changes.

Sincerely,
Watson Ladd
>
> [0] Certainly if we retain any asynchronous handshake or other
>     non-application records post-initial handshake then we must be able
>     to securely distinguish record types!
>
> [1] Certainly if we retain any asynchronous... then we must be able to
>     securely detect replays.
>
> [2] I understand application record replay detection being optional in
>     DTLS.  But certainly it mustn't be for any async handshake records.



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin