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

Alyssa Rowan <akr@akr.io> Thu, 31 December 2015 06:23 UTC

Return-Path: <akr@akr.io>
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 03C8E1A802D for <tls@ietfa.amsl.com>; Wed, 30 Dec 2015 22:23:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Level:
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 h_R_cP2AlJqC for <tls@ietfa.amsl.com>; Wed, 30 Dec 2015 22:23:03 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3526F1A03FF for <tls@ietf.org>; Wed, 30 Dec 2015 22:23:03 -0800 (PST)
To: tls@ietf.org
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>
From: Alyssa Rowan <akr@akr.io>
X-Enigmail-Draft-Status: N1110
Message-ID: <5684C9CC.2080703@akr.io>
Date: Thu, 31 Dec 2015 06:23:08 +0000
MIME-Version: 1.0
In-Reply-To: <CAMfhd9VYAaioMJqsk1M=sEQ-tJ_GJpDk5LsYcydK0Dwv-jQG1g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/yKwxksx83FUnZc7kMw1Aph8aQwU>
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 06:23:05 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-12-31 03:30, Adam Langley wrote:

> 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.

(I have a terrible cold, so apologies if I am less than coherent!)

I think I prefer this, of the available options. Specify that:

• Both client and server MUST abort if X25519 and/or X448 are
  offered/chosen but session_hash is not;
• Explain why in Security Considerations;
• Test as part of interop/unit tests?

Zero checks are more likely to be omitted in practice because all the
implementations out there already do that and don't return a value.
And it's not something the peer would notice in normal operation.

Watson's approach might work too, but of the available options I think
ensuring the transcript is hashed is the most robust with respect to
any future attacks.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWhMnAAAoJEOyEjtkWi2t6wZsQAJk767t5ZE28uDYsSCT1fS9u
z6szG2xGnq6jc4T40AZEWeabs9j0n15MZHvFkxQwmtF00dUspIrcRzpct8hXkx0K
q83rotDKGIiCU9K9a6E4Xas/cxxQ8LDTtB937PsyOIpzPOe/fXHu+KTIgtrLL7Cb
OefYyGf7ymRVm0UP9IrIkK99enu0HPuMjqcDdKfW9JVAvb+jgfTyO+qDipYtH8s0
jo3HhCsMiCJlxFaI32viREW/Jcwu4cyttjCvgOPCQUmJ3TQdAC1ucWXpNHgRp07y
RY3+TJfNx9tmmgOoXvGox67hoKKvFaSO8ckqhXrG/V46xLP2FNDEEsaGd0cuKeEb
7T+/0ae9/mzQm3PYhpufU+FiroTDUuYKvjTHfzEY7xPjjpeQT/OdqyrEseJqFfCC
sCKQQPx40vg1dwU6pJ7KyCEJ14RVY5rXmhvkKjGnfI5tziykKibMnqF1MbPh/BK/
L35fQyeJVb6rAaL8iPJx/ilvdJDESAgWic/UooywWkU8HrH6FAXiIV6i1BmkscXn
e3yQB55SVYHv+yPfcNJAyZDXYVln6EoFwVU3rjYxcnAib2z52m2HOyh7NjrBpvVx
8CuIxU+FytE8BUrkayciOS2AFvGUIsf0c/eogDX9A10U6pOoFCRigLRYKFgRbJ3l
M19UbePdsDBYgnd5sEel
=CRt3
-----END PGP SIGNATURE-----