Re: [Cfrg] Point validation in TLS 1.3

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 30 November 2016 15:02 UTC

Return-Path: <prvs=114284e54a=uri@ll.mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344171294DB for <cfrg@ietfa.amsl.com>; Wed, 30 Nov 2016 07:02:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.695
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWppVwhdMf_f for <cfrg@ietfa.amsl.com>; Wed, 30 Nov 2016 07:02:18 -0800 (PST)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9041295B0 for <cfrg@irtf.org>; Wed, 30 Nov 2016 07:00:33 -0800 (PST)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id uAUEtP4g026723; Wed, 30 Nov 2016 09:55:25 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Thread-Topic: [Cfrg] Point validation in TLS 1.3
Thread-Index: AdJLGn58pKFXm+ukb0SIw60SyivhyQ==
Date: Wed, 30 Nov 2016 15:00:31 +0000
Message-ID: <20161130150039.18280523.1212.104240@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
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: <https://mailarchive.ietf.org/arch/msg/cfrg/tzpcusWZaTXdwWRksxsMvVTLSG4>
Cc: cfrg <cfrg@irtf.org>
Subject: Re: [Cfrg] Point validation in TLS 1.3
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Nov 2016 15:02:22 -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 <Kenny.Paterson@rhul.ac.uk>uk>:
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"
<cfrg-bounces@irtf.org on behalf of ekr@rtfm.com> 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
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg