Le 2016-11-15 15:35, Ilari Liusvaara a écrit :
On Tue, Nov 15, 2016 at 05:02:24PM +0900, Yoav Nir wrote:
I think the performance enhancement (in terms of handshakes per
second)
that you get by reusing ephemeral keys is so great, that we have to
assume people will do it. You don’t have to keep the keys
indefinitely.
It’s fine to generate a new key every second or ten seconds or so.
Which makes running the point validation all the more important.
There's two main reasons for point validation:
1) Preventing leaking of the secret exponent.
2) Preventing key collisions from low-order points.
TLS 1.3 isn't vulernable to 2) like TLS 1.2 and below are (without
EMS).
X25519/X448 have been explicitly designed to resist 1).
If you want to prevent using low-order points for some reason, there is
a handy trick: Check if the output of X25519/X448 is all zeroes or
not, and abort if it is.
There is an unfortunately common mis-conception that X25519 doesn't need
point validation for Diffie-Hellman which comes from the original PR of
Bernstein et al. Curve25519 has an order 8 subgroup that can be used to
do key collisions and transcript synchronization attacks (see III.B.2 in
[1]). The proper validation is to exclude 0, 1,
325606250916557431795983626356110631294008115727848805560023387167927233504,
39382357235489614581723060781553021112529911719440698176882885853963445705823,
2^255 - 19 - 1, 2^255 - 19, 2^255 - 19 + 1, 2^255 - 19 +
325606250916557431795983626356110631294008115727848805560023387167927233504,
2^255 - 19 +
39382357235489614581723060781553021112529911719440698176882885853963445705823,
2(2^255 - 19) - 1, 2(2^255 - 19), and 2(2^255 - 19) + 1. Without this
validation, any one peer of the connection can (mostly) control the
session key, which is mitigated in TLS 1.3 but still an undesirable
property in any compound authentication setting.
Best,
Antoine
[1] http://antoine.delignat-lavaud.fr/doc/ndss15.pdf
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls