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

Brian Smith <brian@briansmith.org> Wed, 30 December 2015 23:54 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F9E1A00A5 for <tls@ietfa.amsl.com>; Wed, 30 Dec 2015 15:54:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 1iTeW1VqrlPU for <tls@ietfa.amsl.com>; Wed, 30 Dec 2015 15:54:28 -0800 (PST)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003: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 50EA81A0095 for <tls@ietf.org>; Wed, 30 Dec 2015 15:54:28 -0800 (PST)
Received: by mail-oi0-x22d.google.com with SMTP id o62so204071265oif.3 for <tls@ietf.org>; Wed, 30 Dec 2015 15:54:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l+ZASjzKBTzhihhz9kk1KUzNMbKkwXAtbYmhm1dhB5c=; b=Te3vNiQ3COYELRaQBOPVpo/eVRlw0zfFsuTN3D2vLgbjMKwaXbTFmu2HJJYdZ4Ujo0 Qfc32L+b2mnqssAntUP3swPodVbkqvZki+8AUwawUHAGbl8k3y7Iz8BGFn5Hyr/JCjBC nWHFtqMBhiDaLMv7yeOp3RG/qLPFP/BV4kO3qrHrjgqpuUFVrgeTBwIZWxk4T8fRrEuC qin+kVVXh4LEy//35F3cFQvbG23XGfBnAsKQyco5RseqJc1Fi2uY+qC5AzdVkqMC5XJH U/7Xzj4qJG9OUF1QUTLESMAkkOg8hXP0qcBWMlIyzHNFMmVwCa4B7Quk1wRz/U+puu7H T5fw==
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:date :message-id:subject:from:to:cc:content-type; bh=l+ZASjzKBTzhihhz9kk1KUzNMbKkwXAtbYmhm1dhB5c=; b=lfkEOSo24TDMo0wHbP+3ccIvFnTphoUdmaRZujuZ4ZLkLLpfmGh0LYf7D/xZyjzuVD g2Z9HrpUY1mq6ZbBL0oT27xZ3jFdNHjhQLwHzm2KOft1lCNc13hva5+EaGgE0xhmmXFI mufJMrSBpq59GwjYDY3pqf5/BWzsv/bamfkAvKmT2pn9/6VNijtxTBkoy2cUTXgWRb2E CQzxKLl3Lp4Q8xGWJuAWPbtbT6ST/gBjUsFTQvxSDMnWjE4jxLsuxV6BpXgury4thcs6 DCcCeHZNKSuyG65+/bfW5vnks+IP6UgQ+CdDTMkhySgnaX2gHzh+U7JXoxTDAchso3rD XUJw==
X-Gm-Message-State: ALoCoQk1BD7nlNov2QUlCd90RPHtccr2H3QPx1OjvAL5EkbTqO/6LyN4zdAY8UFP01/MEUtP0BFY8SEpUJb9lHJdPEV374ZvvA==
MIME-Version: 1.0
X-Received: by 10.202.60.195 with SMTP id j186mr40893188oia.70.1451519667641; Wed, 30 Dec 2015 15:54:27 -0800 (PST)
Received: by 10.76.62.8 with HTTP; Wed, 30 Dec 2015 15:54:27 -0800 (PST)
In-Reply-To: <CABkgnnV+mzt6tQbM7m2hN5Y=Qk8G1AeYtC=+Xy+e31pdEiq-pQ@mail.gmail.com>
References: <CAFewVt4Midtq7X6px4=A4hGkspQuJdzZQ907U=SJox0SdgfAJg@mail.gmail.com> <CACsn0cng1o-5hm=zuL6puOGJ8A2bjB=fFsaFsBCmmVofNSuumg@mail.gmail.com> <CABkgnnXQS3Ek6jDjx0aSQmaf+=EjfGWa8MG1AO4QwhJbK50VQg@mail.gmail.com> <CAFewVt4NSGDP_At8XsX4OsxSUaj_2kRyFP_keDQhfnR0=mBhrg@mail.gmail.com> <CABkgnnUq0_28U6VqE=ZPpwutOBUkTGwhxqHQOEvQve5JYfSVRA@mail.gmail.com> <CAFewVt6fyqbOZfQkWY=9SM20WcrP0UhfH+3wvXjiYoTjPm2pgA@mail.gmail.com> <CAFewVt5U9awAg4FbdWtXiCATd-kWttdsAwe3eWwcD5SXsKvyWQ@mail.gmail.com> <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnV+mzt6tQbM7m2hN5Y=Qk8G1AeYtC=+Xy+e31pdEiq-pQ@mail.gmail.com>
Date: Wed, 30 Dec 2015 13:54:27 -1000
Message-ID: <CAFewVt4d4ExgikFBdizOygU6xHo7z1oeN9YpJAdQVkcGk-oyuw@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=001a113cd33c2cd0ee0528264276
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/U8MR-Er2qN7fqpo2_RJWGlgxrMg>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Dec 2015 23:54:30 -0000

Martin Thomson <martin.thomson@gmail.com> wrote:

> On 30 December 2015 at 22:16, Ilari Liusvaara <ilariliusvaara@welho.com>
> 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/