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

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 31 December 2015 06:54 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 518F91A8704 for <tls@ietfa.amsl.com>; Wed, 30 Dec 2015 22:54:56 -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 4mOxAHUrR8PQ for <tls@ietfa.amsl.com>; Wed, 30 Dec 2015 22:54:54 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 16D161A86FC for <tls@ietf.org>; Wed, 30 Dec 2015 22:54:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 4F6F414B; Thu, 31 Dec 2015 08:54:53 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id BJEkeZHZ34TS; Thu, 31 Dec 2015 08:54:53 +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 F15422310; Thu, 31 Dec 2015 08:54:52 +0200 (EET)
Date: Thu, 31 Dec 2015 08:54:51 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Alyssa Rowan <akr@akr.io>
Message-ID: <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi>
References: <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> <5684C9CC.2080703@akr.io>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5684C9CC.2080703@akr.io>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/2QHVrnyKGwelN324dLpAKl--jVs>
Cc: 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 06:54:56 -0000

On Thu, Dec 31, 2015 at 06:23:08AM +0000, Alyssa Rowan wrote:
> -----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.

The problems with this:

The THS check is a check.

Zero checks can already be unit-tested/interop-tested just as well.

If you do anything that is vulernable to THS, you better take severe
countermeasures at application layer (check for EMS, mix in certs,
refuse resumption, dump and hash transcripts, etc...) already.

As for reliability of using ECDHE... I wouldn't rely that random
implementation of ECDHE is safe against THS, even with cofactor 1
Weierstrass curves. And unit-testing/interop-testing some of the
issues involved is just plain nasty.

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

Actually, I proposed something very similar, but without a hash (HMAC
would likely hash that thing anyway[1]). That one does not have any
checks.



[1] Specifically, unless X25519 is used with ciphersuite with SHA-384
as PRF-hash.




-Ilari