As mentioned before, validating Curve25519 public values is necessary in TLS 1.2 without session hash. Otherwise, as we pointed out in [1], the triple handshake attack returns.
[1] http://www.internetsociety.org/doc/verified-contributive-channel-bindings-compound-authentication <http://www.internetsociety.org/doc/verified-contributive-channel-bindings-compound-authentication> > On 29 Dec 2015, at 21:05, Brian Smith <br...@briansmith.org> wrote: > > On Tue, Dec 22, 2015 at 2:09 PM, Brian Smith <br...@briansmith.org > <mailto:br...@briansmith.org>> wrote: > If an implementation only implements ECDHE cipher suites then implementing > the session hash extension is not necessary, according to RFC 7627. I believe > there are also a few other factors that would implementing the session hash > extension to be unnecessary. > > If checking that the shared value isn't zero is sufficient, and/or > blacklisting the public values that DJB mentions in [1] is sufficient, either > would be better than mandating the implementation of the session hash > extension just for this purpose. > > Actually, the check for a result of zero is already required in the current > CFRG draft; see [1]. So, I think that the easiest way to fix the TLS draft is > to just delete the misleading text. > > [1] https://tools.ietf.org/html/draft-irtf-cfrg-curves-11#section-6.1 > <https://tools.ietf.org/html/draft-irtf-cfrg-curves-11#section-6.1> > Cheers, > Brian > -- > https://briansmith.org/ <https://briansmith.org/> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
