Re: [Cfrg] Point validation in TLS 1.3

["Paterson, Kenny" <[e-mail]>]

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"
<[e-mail] on behalf of [e-mail]> 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
>
>
>
>
>
>
>
>