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

Brian Smith <> Tue, 22 December 2015 23:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2CAC71ABD36 for <>; Tue, 22 Dec 2015 15:23:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HNp3YePWmdtl for <>; Tue, 22 Dec 2015 15:23:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26CDF1A9308 for <>; Tue, 22 Dec 2015 15:23:54 -0800 (PST)
Received: by with SMTP id y66so115921246oig.0 for <>; Tue, 22 Dec 2015 15:23:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KLs6Vx/68kyTqlEPn+536W3R7Q/fEuJyY3ZweKcAiNg=; b=uTbKm0HEz7+BaUPE4cJEdTfmKURPFP+B+V67Qx40sxfvSHtZv3BRlqXj8pezadLvpr 8j3hjUsKO9cBQAyDsssOL8ngwAkQq+8S8ch1YtqdGid+XjxR3OVcVdNg619U5xTad6rR I24ehYsfOcKs1uOWewrF+Rdu565YEnpPdnZB4dVSjklEK0nuEAbKGIrsCARYAN/csb2j Wxsa6HXdjjQKq/8UgJFwv/y8qj+WJDoL7ZfbuWX2KoR4bemfGME+avK8TlXM3crlCRQT mockI8csI6q6mgZUwHQe+WjVNlXKY8SzOy3zo34q/IFDvcMZ7/1R7/V8TSB7nJY5YnfM fLlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KLs6Vx/68kyTqlEPn+536W3R7Q/fEuJyY3ZweKcAiNg=; b=dGRQMjNIlzDx5N0hGaL2cN73Fpm7O4NiqyKx1CgaDaqMXsxxC7f8BGhGLo0lbXsu10 eUNBEG08NehbVytb+TTl5r0NoGKDwjiLowVZTD/I+MC4EO4EUuxVsf4rksTYbTCkilAe CNk6Cw/BRE0MuwAoMEI+eSkXLjZ2A3GNZ1RQSDq6Rjr2tZfhVzl4KiPMggBcy9EkmUJo 7/jIU+GVl12vX2wyLcWgIqU+L0GOC/bIpSQ+mtPmGFDxNeBJwUom75fcMYJgqlergzuL rO3fxFGnrsURzcmFpsZcPK4NAJSyEuz/JZRxEI4dpYJYAxosR05ENSgeV5Zpx7chBK22 6jPQ==
X-Gm-Message-State: ALoCoQnOxuNoEmuDChwCkcpYzRZuichtI5r9bYC9Ssj6FItsb48o6C6Xg56M8uKoeQfNmnlM6jwp+MTX4fryvM9mSecI0XY8Og==
MIME-Version: 1.0
X-Received: by with SMTP id k189mr11917244oif.105.1450826633524; Tue, 22 Dec 2015 15:23:53 -0800 (PST)
Received: by with HTTP; Tue, 22 Dec 2015 15:23:53 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 22 Dec 2015 13:23:53 -1000
Message-ID: <>
From: Brian Smith <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary=001a113cd2b01f5314052784e6a5
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Dec 2015 23:23:57 -0000

Martin Thomson <> wrote:

> Watson Ladd <> wrote:
> > Textbook DH does not ensure contributory behavior. Applications don't
> > implement the required checks for poorly designed protocols. If we insert
> > checks, applications which fail to make those checks will be vulnerable,
> > while fixing protocols closes the hole.
> I've done a fair bit of reading into this issue as well, finding
> Thai's blog posting and a few other things.  As Watson says, the
> protocol can be designed so that it doesn't depend on the DH exchange
> providing contributory behaviour.  We should definitely do that either
> way.

TLS 1.2 and earlier versions are already defined. So, fixing the protocol
is a good solution for TLS 1.3 and later, but draft-ietf-tls-curve25519
also is supposed to work for the versions that can't be fixed.

> I understand that the checks are considered onerous by some, but I
> still don't understand why anyone might refuse to do them.  Checking
> that you don't get a bad output from the DH computation is a tiny
> piece of code that takes almost no time at all, even if you have to
> worry about doing it in constant time.

To be clear, I'm not arguing that the draft should recommend or require
such a check. Merely, I'm pointing out that we have the following
contradictions that the draft doesn't resolve:

1. The draft says that Curve25519 doesn't require public key validation,
full stop.
2. DJB said that Curve25519 may require public key validation for protocols
that require contributory behavior.
3. Thai and Watson both said that TLS 1.2 and earlier require contributory

It may be the case that TLS requires contributory behavior and point
validation is still unnecessary. Or, it may be the case that TLS doesn't
really require contributory behavior (though, it seems obvious to me that
it does, at least for TLS 1.2 and earlier). Or, it may be the case that TLS
requires contributory behavior and a check is necessary. The draft should
make it clear which case we are dealing with, with a reference to the
reasoning that gave us whatever conclusion is reached, but currently that
is missing.