Re: [TLS] Curve25519 and TLS

[Watson Ladd <[e-mail]>]

On Sun, Jun 22, 2014 at 5:56 PM, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Fri, Jun 13, 2014 at 7:05 PM, Watson Ladd <[e-mail]> wrote:
>>
>> On Fri, Jun 13, 2014 at 8:02 PM, Eric Rescorla <[e-mail]> wrote:
>> >
>> >
>> >
>> > On Fri, Jun 13, 2014 at 2:59 PM, Watson Ladd <[e-mail]>
>> > wrote:
>> >>
>> >> On Fri, Jun 13, 2014 at 6:37 PM, Andy Lutomirski <[e-mail]>
>> >> 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).
>
>
> Well, this isn't quite the two cases we are considering, since we are
> computing either:
>
> HMAC(Key, stuff)
>
> or:
>
> HMAC(Key, H(stuff))
>
> with:
> - stuff being under partial control of the attacker and
> - the Key being subject to the issue you raise in the message
> that started this thread.

HMAC is H(key || H(stuff)) right? So it turns into H(key || H(stuff))
vs H(key || H(H(stuff))). (Yes, there is padding: that's an injective
function, so doesn't matter for this analysis). Once again a collision
means stuff equals stuff both ways.

Of course, this presumes resistance to collisions. But if we don't
have that, there is a lot more going wrong.

Sincerely,
Watson Ladd