Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

[Brian Smith <[e-mail]>]

Martin Thomson <[e-mail]> wrote:

> On 30 December 2015 at 22:16, Ilari Liusvaara <[e-mail]>
> wrote:
> >> Would it make sense to have session hash as a requirement in TLS
> >> 1.2 when you want to use Curve25519?
> >
> > I don't think that is reasonable.
>
> I think that is entirely reasonable.  TLS 1.2 relies on contributory
> behaviour.  25519 doesn't provide that unless you do some extra
> checking that we know many implementations don't do.
>

The check for zero is not "extra". It is required by the CFRG draft spec.

Here's my proposed rewrite of this section:


2.3.  Public key validation

   draft-irtf-cfrg-curves-11 specifies how to do the Diffie-Hellman
   computation and the checks that are required.

   Note in particular that [I-D.irtf-cfrg-curves Section 6.1] and
   [I-D.irtf-cfrg-curves Section 6.2] require implementations to
   check, in a side-channel-safe manner, that the result of the
   Diffie-Hellman computation is non-zero. Such a check is essential
   for preventing key dictation attacks in TLS, as described in
   [Contributive Section III.b.3].

   Implementations MAY check that the peer's public value u-coordinate
   is on the curve, but such a check is not necessary when the check
   for a non-zero result is done. The practical consequence of this is
   that public u-coordinates must be reduced modulo the field order
   as required in draft-irtf-cfrg-curves-11 before being transmitted.

[Contributive]
           Bhargavan, K, A. Delignat-Lavaud, and A. Pironti. "Verified
           Contributive Channel Bindings for Compound Authentication",
           Feb 2015,
           <https://www.internetsociety.org/sites/default/files/08_5.pdf>.

I am not sure if [Contributive] is the best reference, but it is the only
one I know of that actually addresses the issue specifically for TLS and
these curves.

Cheers,
Brian
-- 
https://briansmith.org/