Re: [Cfrg] Point validation in TLS 1.3

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Wed, 30 November 2016 13:44 UTC

Return-Path: <smyshsv@gmail.com>
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 59F18129888 for <cfrg@ietfa.amsl.com>; Wed, 30 Nov 2016 05:44:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HEEY1lpOcHew for <cfrg@ietfa.amsl.com>; Wed, 30 Nov 2016 05:44:04 -0800 (PST)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 AAEB41298B9 for <cfrg@irtf.org>; Wed, 30 Nov 2016 05:42:37 -0800 (PST)
Received: by mail-io0-x22d.google.com with SMTP id a124so348369896ioe.2 for <cfrg@irtf.org>; Wed, 30 Nov 2016 05:42:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eWKgAYxQvKJ2bVlnptZBw2dqItPFmSVMYFfW1TTUhWk=; b=vIN+iHR65PN5iHE82KFjpnWNvi4Zq2eOYvac8VVAROXTv3yrc5RzCl5Kr+mMFEk/Wv LN+o1os0Jp8Fx0ET9Jpts/mTWqVyyD58OTrbxnxI9Ye16DK5Nh+QaSl2SRSqgFQL1E6m hwTMk4DL/UpWbtvTxPpAcyv8jn7ZLrR1znBFCfGXciram53h9qD8sxTYQj/IGrvE7rqX mZKHYvZVXBxTuuOcXOfyShs78MHKVoJAkIXRCdgHWW//RON81v9eGuE8iPhIyGWhVnDb SQFB+2Rnns4JtifjFzNxeDmMEyqcZeBoKw7VE6QF2JWannNb+BTYemZhgfGDeBfD0GwF gS1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eWKgAYxQvKJ2bVlnptZBw2dqItPFmSVMYFfW1TTUhWk=; b=LMlOaxiq7wJSTb4OOW+EhXuNemnGj675fS19CIeEY3OaHqMrn7Fl2bH8/ijEnkJt2p olTiic5ob4FRUjhumuWUP6Dkra5oQIba8gKdDCTfSi9a/CbNO6NSr6FjjkOeEgFHKjyT 1tf4SqkJCWKKdadXgTMFpy4FDJ+/dGPZwGLgQvIj813C8DGOguB7nNf42eMzddwkRqLY ZcGornpES46624arXq6cFE6iY+kP6mBNPbbs0nSfdM/o7vDF/8C1A47bV7SscX7gIb+B f2A5INn91EVeqx+UoQbqK+3TVMb10ddrHOoV47Q7D8XbS/k7iAa4BTfLDGDf7y82Fw8I N+rQ==
X-Gm-Message-State: AKaTC033DmXlPLnLQQv0u2/oI/t4flEVV8mOu5HdkybmkkMqHa+jLbBNtjgtJo0ocpee0k7ug8ebH9zTgzGQkQ==
X-Received: by 10.107.134.20 with SMTP id i20mr27610141iod.209.1480513357054; Wed, 30 Nov 2016 05:42:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.33.165 with HTTP; Wed, 30 Nov 2016 05:42:36 -0800 (PST)
In-Reply-To: <D46467DD.7B728%kenny.paterson@rhul.ac.uk>
References: <CABcZeBMswwn1wJkokf9OzYX8f1PH7gJv2a6RoDDao1V=zqcbVg@mail.gmail.com> <D46467DD.7B728%kenny.paterson@rhul.ac.uk>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Wed, 30 Nov 2016 16:42:36 +0300
Message-ID: <CAMr0u6kHEe11CQu1oLQWWteJ6=6-8-4tUST-bgVGAto9po4nSQ@mail.gmail.com>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Content-Type: multipart/alternative; boundary=001a113ec7f2bb8a75054284e0a9
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/uI7v6BouO8DqVc99P6E4C-928Aw>
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 13:44:06 -0000

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
>