Re: [TLS] Curve25519 and TLS

On Fri, Jun 13, 2014 at 8:02 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Fri, Jun 13, 2014 at 2:59 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>> On Fri, Jun 13, 2014 at 6:37 PM, Andy Lutomirski <luto@amacapital.net>
>> wrote:
>> > On 06/13/2014 02:30 PM, Watson Ladd wrote:
>> >> For TLS 1.3 we should ensure contributory behaviour is not required to
>> >> avoid these issues.
>> >
>> > What needs to change for this to be the case?  It would be even nicer if
>> > the result were provably correct in some reasonable model.
>>
>> Hash the entire exchange into the generated key, so that a key made by
>> someone cheating is only shared with them. I still don't understand
>> why this isn't done already: it's needed for the finished message, so
>> nothing is saved by not doing it. This is what the triple handshake
>> fix is supposed to do, but it does a strange variant that reuses the
>> oddball finished message.
>>
>> (And use a strong hash function: apparently the reason we haven't
>> finished fixing Triple Handshake is that some people want to use
>> SHA-1. On their heads be it!)
>
>
> Hmm... I don't believe that this isn't done strictly because of SHA-1.
> Looking back at what I wrote a while ago:
>
> http://www.ietf.org/mail-archive/web/tls/current/msg12574.html
>
> I believe the question is whether it is acceptable to have a *hash* of
> the handshake hashed into the generated key as opposed to having
> the handshake itself hashed into the generated key and whether it's
> acceptable to have that hash be the combined MD5/SHA1 variant
> in TLS < 1.2 and if not what recommendation we should make for
> those versions.

Why wouldn't it be? If H(m)=H(m'), that's just as much a collision as
if H(m || stuff)=H(m' || stuff).

The MD5/SHA1 combination is only as strong as SHA1 against collisions.
In versions before TLS 1.2 this is unavoidable.
If that isn't good enough, the only recommendation I can offer is
don't use SHA1, but SHA2.
>
> -Ekr
>
>>
>> If the protocol is simple enough CryptoVerif can do the proofs with
>> some prodding: proving shouldn't really be the issue. Hashing helps
>> here by enabling the formation of a concept of "matching exchange",
>> and thus significantly constraining an attacker.
>>
>> Sincerely,
>> Watson Ladd
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>

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