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

Brian Smith <brian@briansmith.org> Thu, 31 December 2015 03:40 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 03DB11A6F2F for <tls@ietfa.amsl.com>; Wed, 30 Dec 2015 19:40:55 -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 I4_ZNcQJvWB1 for <tls@ietfa.amsl.com>; Wed, 30 Dec 2015 19:40:53 -0800 (PST)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 85EA91A6F29 for <tls@ietf.org>; Wed, 30 Dec 2015 19:40:53 -0800 (PST)
Received: by mail-ob0-x231.google.com with SMTP id 18so282975729obc.2 for <tls@ietf.org>; Wed, 30 Dec 2015 19:40:53 -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=CqLtdKRTdmmKKB14OXMMAu2EGu6rlYU0cn1E4P+f4o0=; b=MmckVbysaSfboYjzfQvR78qWjgRUdi3iV8UkS+yLArzTH8MZiSIhi5vc2OyfSvB54Z 2oxk0iF5DZw7UATw/gl58w0gyAasRq8EqO1qVCvczk8Fsg9Eu5NqEzsX3D+Lqh53a/M8 lExS69bal4yrxeN/ZCIgpRfVxvNZvznMrEjhZt664dbGC3o0RwhCTd5MAxy1KQuEN1fJ Yejcq38zX29B/RNirnP7NVKw/sw3nM/5m5ykCHWpGQW/3ELdx4QtxJX4bNHvp+j8nfrp m1NuL6jjWxqHJzqI3UGxR+iXaqsXcwi2pkOPN9KzRnt1UsJPF4/3vUDpQxGpPPkRCuZA ItOA==
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=CqLtdKRTdmmKKB14OXMMAu2EGu6rlYU0cn1E4P+f4o0=; b=IfqlkEbUXAeWufKTxAI/Vsi5I3pBWim1bGaS4SX8WxtKZTMST+9kSJpl0JVQ2tzpf6 aei5KQNRwcj9y3NjhSijAqqKUkL9+ZgQ0ghdsuYb2AR4kz8llt59bheLFmyFAV+BVZDR jkussNDrmuPok/cVAUNy2LKNE01Fj4MKICG/mVFKQoyXaoneeRaBV1oZ34noSyu89/oi CTwvzw8krux1jcWhvuEc1jf9nphK7cXOE+tP9A2Sjas4oZmfdF8tzNSU2ZvatmRjdy/B r/81NtgqU2MWuZYygLU84EJq9Haw6hp03gcMn27RIp7M6K2KnSJ1Hq8gLU2Ic7GKu4En QDyA==
X-Gm-Message-State: ALoCoQkv2LDSU3isI3yUH6Bg6eoGtfYcgp1g/FL25cbQ6MJNN72VerkdpNQfaG36fc94GL0nzTG7tCrCQzShVv7QCYzAmV9icw==
MIME-Version: 1.0
X-Received: by 10.60.134.202 with SMTP id pm10mr14467090oeb.50.1451533252894; Wed, 30 Dec 2015 19:40:52 -0800 (PST)
Received: by 10.76.62.8 with HTTP; Wed, 30 Dec 2015 19:40:52 -0800 (PST)
In-Reply-To: <CAMfhd9VYAaioMJqsk1M=sEQ-tJ_GJpDk5LsYcydK0Dwv-jQG1g@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> <CAFewVt4+eysHvxnP=q-Gn-0DgQWLkoTs5OSc8v_t6qRtsk7TWg@mail.gmail.com> <CAMfhd9VYAaioMJqsk1M=sEQ-tJ_GJpDk5LsYcydK0Dwv-jQG1g@mail.gmail.com>
Date: Wed, 30 Dec 2015 17:40:52 -1000
Message-ID: <CAFewVt53X5z-FB_myBNiQF7rTaLw17ANtSOnwWbFcUeLYd8Law@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Adam Langley <agl@imperialviolet.org>
Content-Type: multipart/alternative; boundary="047d7b417a63eb3c960528296b50"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/WDf2w6VItJeRB3i_10S1OSfBXHE>
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: Thu, 31 Dec 2015 03:40:55 -0000

Adam Langley <agl@imperialviolet.org> wrote:

> On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith <brian@briansmith.org> wrote:
>
> > I think it is a good idea to implement the session hash extension, in
> > general. However, I think it is a bad idea to prescribe it as the
> solution
> > for this particular problem because:
> >
> > 1. draft-irtf-cfrg-curves-11, in sections 6.1 and section 6.2 already
> > require the check for a non-zero result, and that check is sufficient.
>
> As discussed on the CFRG list, the plan is that the final curves RFC
> will say that the zero check is a MAY. (See
> https://www.ietf.org/mail-archive/web/cfrg/current/msg07611.html)
>

When you say "the plan," whose plan are you referring to? If you read that
whole thread, there was a lot of well-founded opposition to that plan. And,
that plan was never carried out. That is plain to see, as there was never a
draft submitted with such a change. So, I assumed that "the plan" was
dropped. This isn't a minor editorial change, so it wouldn't be appropriate
(IMO) to have the final spec changed in this respect without having had
that change reflected in any draft that people have actually been reviewing.


> I don't mind if the integration of curve25519 in TLS requires a
> zero-check or not, but what property are people hoping to gain? If one
> wants to avoid triple-handshake like issues then session-hash is the
> answer.


Session Hash is *an* answer, but, for the reasons I already gave in this
thread, it isn't the best answer for this.

A client can use an RSA key exchange to control the PMS
> completely, of course, and, with finite-field DH, a value of zero or
> p-1 will usually allow the same.


Not if the implementation doesn't implement RSA or finite-field DH.

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