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

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 31 December 2015 20:46 UTC

Return-Path: <ilariliusvaara@welho.com>
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 9BD9B1A8AE5 for <tls@ietfa.amsl.com>; Thu, 31 Dec 2015 12:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 aMQgiJlYN_f7 for <tls@ietfa.amsl.com>; Thu, 31 Dec 2015 12:46:07 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 93D9F1A8AE4 for <tls@ietf.org>; Thu, 31 Dec 2015 12:46:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 827DE17A; Thu, 31 Dec 2015 22:46:06 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 93ZTfdAGg-vQ; Thu, 31 Dec 2015 22:46:06 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 1A1C4230D; Thu, 31 Dec 2015 22:46:06 +0200 (EET)
Date: Thu, 31 Dec 2015 22:46:05 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20151231204604.GB24791@LK-Perkele-V2.elisa-laajakaista.fi>
References: <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> <20151231000803.GA23937@LK-Perkele-V2.elisa-laajakaista.fi> <CACsn0c=Wmy9oqnDFuhBY-YUSSYv2Wf-Wf09he+vjwvko=eciFg@mail.gmail.com> <CAFewVt5GinBy=eE3OmTyZ3UHibuS0NM-TQOyF=Dqaut--WX-Jw@mail.gmail.com> <CACsn0cno2uMo6b5NV=pdq9X_0rBXHiZi6RuUi141C-somwc6+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CACsn0cno2uMo6b5NV=pdq9X_0rBXHiZi6RuUi141C-somwc6+Q@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/z3wPP4aTHlI_q8mN3WQ3EUK-MvY>
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 20:46:09 -0000

On Wed, Dec 30, 2015 at 09:16:12PM -0500, Watson Ladd wrote:
> On Wed, Dec 30, 2015 at 7:47 PM, Brian Smith <brian@briansmith.org> wrote:
> > Watson Ladd <watsonbladd@gmail.com> wrote:
> >
> > Actually, because the check for non-zero result can/should/is in the
> > X25519/X448 functions themselves, the check for non-zero result is the least
> > likely of all these possible solutions to be omitted. And, it is also the
> > easiest to test.
> 
> Failure to compute H(A, B, X25591(a, B)) would result in an
> interoperability failure with any other implementation of this
> ciphersuite. By contrast a zero check will not be exercised by basic
> interoperability testing, nor would mandatory use of session hash.

Actually, I figured out an attack. Which also breaks my original scheme
(except in one rare case).


A hack to break that attack would be to zero-pad the hash output to
minimum of 48 bytes and then to append (prepending won't work)
something nonzero (e.g the group id, that is 00 29 for X25519 and
00 30 for X448).


-Ilari