Subject: [TLS] Point validation in 1.3

From: Watson Ladd <[email-masked]>
Date: Mon, 14 Nov 2016 23:16:45 -0800

Hello,

There has been a lot of chatter on Gitub about point validation. I think
it's important to note that in TLS 1.3 the Triple Handshake variants
enabled by small subgroup attacks are no longer a threat: the issue is
reuse of ephemeral Diffie-Hellman exponents, resulting in compromise of
what is effectively a long-term key.

I would want a belt and suspenders approach: no use of ephemeral exponents,
and validation that points are on the curve. Order validation is
unnecessary as the cofactor is small: in cases where it is not the curve
probably shouldn't be used without a good reason, and I can't think of any.

I know one implementation does keep ephemeral exponents indefinitely. This
implementation also validates orders, which equals the expense of not
regenerating ephemeral exponents.

Sincerely,
Watson

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Nov 2016 16:46:10 +0900

> I would want a belt and suspenders approach: no use of ephemeral

Just to clarify, you mean "no reuse", right?

-Ekr

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Nov 2016 17:02:24 +0900

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.

Yoav

> On 15 Nov 2016, at 16:16, Watson Ladd <[email-masked]> wrote:
> 
> Hello,
> 
> There has been a lot of chatter on Gitub about point validation. I think it's important to note that in TLS 1.3 the Triple Handshake variants enabled by small subgroup attacks are no longer a threat: the issue is reuse of ephemeral Diffie-Hellman exponents, resulting in compromise of what is effectively a long-term key.
> 
> I would want a belt and suspenders approach: no use of ephemeral exponents, and validation that points are on the curve. Order validation is unnecessary as the cofactor is small: in cases where it is not the curve probably shouldn't be used without a good reason, and I can't think of any.
> 
> I know one implementation does keep ephemeral exponents indefinitely. This implementation also validates orders, which equals the expense of not regenerating ephemeral exponents. 
> 
> Sincerely,
> Watson

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 15 Nov 2016 17:35:55 +0200

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

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.

-Ilari

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Thu, 17 Nov 2016 14:58:58 +0000

> a handy trick: Check if the output of X25519/X448 is all zeroes or

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

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Thu, 17 Nov 2016 16:13:49 +0000

Le 2016-11-17 14:58, Antoine Delignat-Lavaud a écrit :
> 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,

I misunderstood your message, if you check the output of the 
multiplication with the peer public key rather than the public key 
itself, checking for 0 is indeed the easiest (and safe) check to 
perform.

Antoine