Re: [TLS] Curve25519 and TLS

[Eric Rescorla <[e-mail]>]

On Sun, Jun 22, 2014 at 6:24 PM, Watson Ladd <[e-mail]> wrote:

> 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?


Actually: H(key^mask1 || H(key^mask2 || stuff))

where mask1 and mask2 are fixed.



> 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.


Sorry, my mistake for not being clearer: I was assuming that there
was at least some partial failure of collision resistance in the hash
function. As you suggest, that means that a lot of other stuff is going
wrong, so maybe it's not worth worrying about.

-Ekr