Subject: Re: [Cfrg] Point validation in TLS 1.3

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 30 Nov 2016 15:00:31 +0000

+1

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Stanislav V. Smyshlyaev
Sent: Wednesday, November 30, 2016 08:44
To: Paterson, Kenny
Cc: cfrg
Subject: Re: [Cfrg] Point validation in TLS 1.3

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]>:
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

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

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

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