Re: [TLS] Curve25519 and TLS

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.

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