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>:

> 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
>