Re: [TLS] Curve25519 and TLS

[Bodo Moeller <[e-mail]>]

Watson Ladd <[e-mail]>:

>> Alternatively we can compute the premaster secret as the hash of H(ag
> >> | bg | abg): I have not yet confirmed that this solves the problem.
>


> > Hm, this looks like something that rather belongs into the premaster
> secret
> > => master secret step.  If you have this there (such as when you're using
> > the proposed Extended Master Secret Extension
> > [draft-bhargavan-tls-session-hash-00]), including the public keys here
> too
> > would be redundant.  If you'd normally be doing a public-key check or an
> > ECDH result check, you could just skip this check if the protocol no
> longer
> > has a need for such protection.  In contrast, if you hash those
> additional
> > inputs when computing the premaster secret, that's not something you
> could
> > remove without affecting compatibility.
>


> Yes, we could make EMSE a dependency of Curve25519. Or we could change
> the way we compute
> the PMS to avoid doing this: I proposed this solution because its very
> simple for some implementations.
>
> What do we gain from having the PMS calculated the same way for each curve?
>

My argument wasn't about doing things the same way for each curve. What I
don't like is introducing overhead (hashing an input at the premaster
secret level that we'll be hashing at the master secret level too, in
certain protocol variants) that could be avoided by using your other
proposal, a Curve25519-specific check.

(For many hashes, it would be actual computational overhead because those
two public keys are large enough to take up an additional input block.)