Subject: [Cfrg] Point validation in TLS 1.3

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Nov 2016 17:52:46 -0500

Hi CFRG folks,

Matt Green has submitted a pull request to require validation for ECDHE
(TLS 1.3 already requires it for FFDHE). We wanted to make sure the CFRG was
aware of this and see if there were objections.

PR is here:
https://github.com/tlswg/tls13-spec/pull/763

Text:
For the curves secp256r1, secp384r1 and secp521r1, the appropriate
validation procedures are defined in Section 4.3.7 of {{X962}} and
alternatively in Section 5.6.2.6 of {{KEYAGREEMENT}}.  This process
consists of three steps: (1) verify that Y is not the point at
infinity (O), (2) verify that for Y = (x, y) both integers are in the
correct interval, (3) ensure that (x, y) is a correct solution to the
elliptic curve equation.  For these curves, implementers do not need
to verify membership in the correct subgroup.

For x25519 and x448, the contents of the public value are the byte
string inputs and outputs of the corresponding functions defined in
{{RFC7748}}, 32 bytes for x25519 and 56 bytes for x448. Peers SHOULD
use the approach specified in {{RFC7748}} to calculate the
Diffie-Hellman shared secret, and MUST check whether the computed
Diffie-Hellman shared secret is the all-zero value and abort if so, as
described in Section 6 of {{RFC7748}}. If implementers use an
alternative implementation of these elliptic curves, they should
perform the additional checks specified in Section 7 of {{RFC7748}}.

Thanks in advance for your input,
-Ekr

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 30 Nov 2016 03:06:55 +0000

Eric Rescorla <[email-masked]> writes:

>Matt Green has submitted a pull request to require validation for ECDHE (TLS
>1.3 already requires it for FFDHE). We wanted to make sure the CFRG was aware
>of this and see if there were objections.

So this runs into the same issue I've run into in -LTS, which means it's a
convenient time to bring it up: What is it that the implementer reading the
spec needs to verify?  In other words during a TLS handshake, what data
exchanged in the handshake must be checked with:

  This process consists of three steps: (1) verify that Y is not the point at
  infinity (O), (2) verify that for Y = (x, y) both integers are in the
  correct interval, (3) ensure that (x, y) is a correct solution to the
  elliptic curve equation.

Peter.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 30 Nov 2016 11:27:07 +0000

Hi Eric,

Thanks for giving CFRG the chance to comment on this.

From a technical perspective, this looks like an accurate translation of
existing best practice to me.

Any other comments from the group?

Cheers

Kenny

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Wed, 30 Nov 2016 16:42:36 +0300

Dear Eric and Kenny,

The text looks smart and convenient, but, to be honest, I'd prefer that it
would be a little more restrictive (only one small change).

Instead of "Peers SHOULD use the approach specified in {{RFC7748}}", in my
opinion, there'd better be "MUST". Otherwise, an undesirable situation (of
obtaining a resulting non-zero key on a small subgroup) with x25519 and
x448 may occur, if ECDH on them would be done without multiplication by
cofactors and without (specified in Section 5 of RFC 7748) zeroisation
of three/two
least significant bits.

Best regards,
Stanislav Smyshlyaev

2016-11-30 14:27 GMT+03:00 Paterson, Kenny <[email-masked]>:

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Dan Brown <[email-masked]>
Date: Wed, 30 Nov 2016 18:19:21 +0000

Hi Eric and Kenny,

Please consider adding a MAY for the redundant ("belts and suspenders") combination of point validation and Montgomery ladder (X25519).
 
Significant costs of this redundant combination are its being approximately 10% slower in each DH computation and its extra code.

A small benefit of this redundant combination is its being potentially minutely securer (see * below). 

A user or an implementer should only want this combination when the extra cost is somehow negligible (for example, in comparison to other large costs) because the benefits are likely close to negligible.

The user and implementer should be well-informed to make a useful decision.  The work of preparing a clear guidance in the RFC on cost (significant) and benefits (insignificant) might outweigh the benefit of having a MAY in the RFC.

Best regards,

	Dan

(*) Here's how I think (for now) that directly rejecting twist-points on top of X25519 might minutely improve security:

- a denial of service attack consisting of just sending random strings as points is better resisted, 
- a user of the implementation can be more confident that something fishy doesn't happen if twisted points are received (the user can delay inspecting the internal of the implementation and just examine its behavior),
- validation is to be done on the public inputs received, before any secrets are used, which is generally safer (more robust against implementation bugs).

Again, the gain in all cases is small (at best) because each threat thwarted can be tweaked easily to work around to the countermeasure.

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Paterson, Kenny
Sent: Wednesday, November 30, 2016 6:27 AM
To: Eric Rescorla <[email-masked]>; cfrg <[email-masked]>
Subject: Re: [Cfrg] Point validation in TLS 1.3

Hi Eric,

>From a technical perspective, this looks like an accurate translation of existing best practice to me.

Cheers

Kenny 

On 29/11/2016 22:52, "Cfrg on behalf of Eric Rescorla"
<[email-masked] on behalf of [email-masked]> wrote:

>consists of three steps: (1) verify that Y is not the point at infinity 
>(O), (2) verify that for Y = (x, y) both integers are in the correct 
>interval, (3) ensure that (x, y) is a correct solution to the elliptic 
>curve equation.  For these curves, implementers do not need to verify 
>membership in the correct subgroup.
>
>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 30 Nov 2016 23:07:03 +0000

Hi Dan,

Thanks for sharing your views.

I'd appreciate hearing from interested CFRG participants on whether
implementing this "MAY" would bring meaningful additional security benefit
for implementations or not.

Regards,

Kenny 

On 30/11/2016 18:19, "Dan Brown" <[email-masked]> wrote:

>Hi Eric and Kenny,
>
>Please consider adding a MAY for the redundant ("belts and suspenders")
>combination of point validation and Montgomery ladder (X25519).
> 
>Significant costs of this redundant combination are its being
>approximately 10% slower in each DH computation and its extra code.
>
>A user or an implementer should only want this combination when the extra
>cost is somehow negligible (for example, in comparison to other large
>costs) because the benefits are likely close to negligible.
>
>The user and implementer should be well-informed to make a useful
>decision.  The work of preparing a clear guidance in the RFC on cost
>(significant) and benefits (insignificant) might outweigh the benefit of
>having a MAY in the RFC.
>
>Best regards,
>
>	Dan
>
>(*) Here's how I think (for now) that directly rejecting twist-points on
>top of X25519 might minutely improve security:
>
>- a user of the implementation can be more confident that something fishy
>doesn't happen if twisted points are received (the user can delay
>inspecting the internal of the implementation and just examine its
>behavior),
>- validation is to be done on the public inputs received, before any
>secrets are used, which is generally safer (more robust against
>implementation bugs).
>
>Again, the gain in all cases is small (at best) because each threat
>thwarted can be tweaked easily to work around to the countermeasure.
>