Re: [Cfrg] Point validation in TLS 1.3

"Paterson, Kenny" <> Wed, 30 November 2016 23:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E27D129BC2 for <>; Wed, 30 Nov 2016 15:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TJw3BpKrvf6t for <>; Wed, 30 Nov 2016 15:07:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FDA2129514 for <>; Wed, 30 Nov 2016 15:07:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HoGPhdFu9JmTiWpaYZtXWzbsBcqNuSwwhpLmBUYWy2Y=; b=4CsC7pKnYDYv3/8+jrHDyfnKaRJIlMYzFzQVpidGyCHUsqTw+1xKnoyAbFfX6edoWw8+n2SVI50MQdY0MFUyif6DUevTKfe2Jx2F9p+ESIg0UZAg5of8A+j7eWCjRDrruNWMUkIVPb2LQM4cjw7+uE9UcWBmbKbVmI5+5Uj9TYo=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Wed, 30 Nov 2016 23:07:03 +0000
Received: from ([]) by ([]) with mapi id 15.01.0747.015; Wed, 30 Nov 2016 23:07:03 +0000
From: "Paterson, Kenny" <>
To: Dan Brown <>, Eric Rescorla <>, cfrg <>
Thread-Topic: [Cfrg] Point validation in TLS 1.3
Thread-Index: AQHSSpOFqO2MoKrGok6jXbDda/qr36DxZEgAgABzG4CAAFCMAA==
Date: Wed, 30 Nov 2016 23:07:03 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; HE1PR0302MB2746; 7:z3ECkO1Rfv5P1FHjjWTmzw820p3NMefkt+Y+lmC1T2tInNdZoMZqNiDtObDLpQVlRU6O32bCOgNavuqtcMIeBxEI//54i4duT2mrHWHN6o0X7ekIQYr9p8iyu/FqYjcLCu1lwLyuIk7rCr0Mp7S0lt2wqjwrxKuepMe7uH3V4iHa7CCbAR5CWu44LIyYcDt6GHRjz2zHJWs+J0bdTmDJA+j+QrmmXzNmI88IaOZDsdsdPMVdHEd4PgIdpGWdBignZpeygmyr7zfCqGL3GKovHE3eMP0tCLNM/lfD2oKKyzEWeKOnchF61waE0le8zh2J7w+bTxroVsbIxOThaDbglWz5xyCrok3iaZTrffbl5IKN2FNxL4nKV+YDJbdGzilfYFoxtyje+cIhcELQNOd2NFT9ZJxdE0/DFOBrCYXtw9wyYgksGaeLaD700EYUkcF3SeNwjuMMy+EG5Y6OqtPkuQ==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(199003)(24454002)(51874003)(189002)(377454003)(229853002)(68196006)(97736004)(39450400002)(81156014)(8936002)(3660700001)(74482002)(106356001)(81166006)(122556002)(8676002)(68736007)(106116001)(4001350100001)(6506003)(2900100001)(6486002)(92566002)(77096006)(76176999)(3280700002)(6512003)(107886002)(54356999)(189998001)(5660300001)(105586002)(7846002)(2950100002)(83506001)(36756003)(42882006)(101416001)(86362001)(50986999)(5001770100001)(38730400001)(7736002)(305945005)(2906002)(66066001)(6116002)(3846002)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0302MB2746;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: 4d345058-41c0-43c6-3921-08d419759920
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0302MB2746;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:HE1PR0302MB2746; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0302MB2746;
x-forefront-prvs: 0142F22657
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2016 23:07:03.5104 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0302MB2746
Archived-At: <>
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 23:07:10 -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.



On 30/11/2016 18:19, "Dan Brown" <> 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 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
>- 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 [] On Behalf Of Paterson, Kenny
>Sent: Wednesday, November 30, 2016 6:27 AM
>To: Eric Rescorla <>; cfrg <>
>Subject: Re: [Cfrg] Point validation in TLS 1.3
>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 was
>>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