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>: > 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 >
- Re: [Cfrg] Point validation in TLS 1.3 Blumenthal, Uri - 0553 - MITLL
- [Cfrg] Point validation in TLS 1.3 Eric Rescorla
- Re: [Cfrg] Point validation in TLS 1.3 Peter Gutmann
- Re: [Cfrg] Point validation in TLS 1.3 Paterson, Kenny
- Re: [Cfrg] Point validation in TLS 1.3 Stanislav V. Smyshlyaev
- Re: [Cfrg] Point validation in TLS 1.3 Dan Brown
- Re: [Cfrg] Point validation in TLS 1.3 Paterson, Kenny