[Cfrg] Point validation in TLS 1.3

Eric Rescorla <ekr@rtfm.com> Tue, 29 November 2016 22:54 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B6DB812945D for <cfrg@ietfa.amsl.com>; Tue, 29 Nov 2016 14:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Sm_Vhp8G1tn3 for <cfrg@ietfa.amsl.com>; Tue, 29 Nov 2016 14:54:01 -0800 (PST)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E2D12948D for <cfrg@irtf.org>; Tue, 29 Nov 2016 14:53:27 -0800 (PST)
Received: by mail-yw0-x232.google.com with SMTP id a10so146896336ywa.3 for <cfrg@irtf.org>; Tue, 29 Nov 2016 14:53:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=/lKfkdPFlHHkCFNoTrKSNT2G1PCU01tkx3d0p89U06o=; b=PfHxyTbmazmbA8pPDVy9VggPFKXj2VZfQK+s7HKAfXPC/kZ6840uNV4Jyb/okiBoB0 DCJg9MwnnSUqPhsMOs/10FYD1Yms3LJ34ckwJWK0BD85huGI9tTj8peS2sWOnIfFDQss GUAOhonU14LKeFfZyH/bSjlj4sQOLRa7ltSTSuNMu2cBAUPmfUcbRXUNmPtV54qg9aW0 KqkDjTZNJsPONUWmaI6aQMIogVeNS7XZDfxEKrmoaYaZWLMwQ9Ks4UI+p8kawJmoBC9Z yxbl1I8RJsmoEzNhg6gwLy8KW6jNLPAmT86kOC0jriZHlyUDJy6XRThnSifbAf2UigFI NrLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/lKfkdPFlHHkCFNoTrKSNT2G1PCU01tkx3d0p89U06o=; b=ctqUc5PULsgeD3Do3YVHX33ZbQieTgc1VXBkR5Aimd602KkyaftLYreMBO374kHott Ha6/vlH/+So/jbir/+sAged4MMSfon8Jie7ADetNkAoMuyQ0an0W2h4d/yxbbNfAqa5Z dulPQx1jMpL0ctQk58UY8dyR/m0+t/AkfoKb24mmujnPPzvc0TT4IdWbdrdo5rNgHeqI Y1psGWefwRVr8qZRBcGoDmKnyfEIs1MHgxhTs2vYs7OM56urj4a8UIGA42IU5HqyF5S0 X6/2Eut+SqIWlHSsKkT2KYvIu3KeMfwsyYx1KQFQJAE3YX/vfNrN5YzX/lnn/sDPdlfA tw7Q==
X-Gm-Message-State: AKaTC03aR9uz2hsRqmBGr/k1A2oRkaqJW1xMwpAcD7Y0VhjK/j1CFWOhDSz2Q5LgnbwRNISD1w+hSb4K7VzG7Q==
X-Received: by with SMTP id y206mr32288273ywc.234.1480460006501; Tue, 29 Nov 2016 14:53:26 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 29 Nov 2016 14:52:46 -0800 (PST)
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 29 Nov 2016 17:52:46 -0500
Message-ID: <CABcZeBMswwn1wJkokf9OzYX8f1PH7gJv2a6RoDDao1V=zqcbVg@mail.gmail.com>
To: cfrg <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="001a11492dfacb0b7105427874ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/IsbFub7oCAC7KpwKUBQYVJ-SuwI>
Subject: [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: Tue, 29 Nov 2016 22:54:03 -0000

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,