Re: [Cfrg] Point validation in TLS 1.3

"Blumenthal, Uri - 0553 - MITLL" <> Wed, 30 November 2016 15:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 344171294DB for <>; Wed, 30 Nov 2016 07:02:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.695
X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mWppVwhdMf_f for <>; Wed, 30 Nov 2016 07:02:18 -0800 (PST)
Received: from (LLMX2.LL.MIT.EDU []) by (Postfix) with ESMTP id 6D9041295B0 for <>; Wed, 30 Nov 2016 07:00:33 -0800 (PST)
Received: from ( by (unknown) with ESMTP id uAUEtP4g026723; Wed, 30 Nov 2016 09:55:25 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: "Stanislav V. Smyshlyaev" <>, "Paterson, Kenny" <>
Thread-Topic: [Cfrg] Point validation in TLS 1.3
Thread-Index: AdJLGn58pKFXm+ukb0SIw60SyivhyQ==
Date: Wed, 30 Nov 2016 15:00:31 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="===============1333921135=="
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-30_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611300246
Archived-At: <>
Cc: cfrg <>
Subject: Re: [Cfrg] Point validation in TLS 1.3
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Nov 2016 15:02:22 -0000


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



On 29/11/2016 22:52, "Cfrg on behalf of Eric Rescorla"
< on behalf of> 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
>aware of this and see if there were objections.
>PR is here:
>For the curves secp256r1, secp384r1 and secp521r1, the appropriate
>validation procedures are defined in Section 4.3.7 of {{X962}} and
>alternatively in Section 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,

Cfrg mailing list