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

Eric Rescorla <ekr@rtfm.com> Thu, 31 December 2015 15:55 UTC

Return-Path: <ekr@rtfm.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 924CA1A1B8B for <tls@ietfa.amsl.com>; Thu, 31 Dec 2015 07:55:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 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] 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 MQxQ1csQJJO9 for <tls@ietfa.amsl.com>; Thu, 31 Dec 2015 07:55:13 -0800 (PST)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 71E911A1B89 for <tls@ietf.org>; Thu, 31 Dec 2015 07:55:13 -0800 (PST)
Received: by mail-yk0-x22d.google.com with SMTP id v14so89225957ykd.3 for <tls@ietf.org>; Thu, 31 Dec 2015 07:55:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lRK4ieNOLQgxsRlb7x2V3Z6GtpySWAKKeZqzedYQMbU=; b=oSWV8kxliMrjni3Ct5DPjHbrgWXaxikkZ0MIsLkloduDbxZUHoAyWAA4/41MVlYwTl 07bL4/MeRnTCASd6bi7WO7fitg+taX+/MxXbh+AG18mCHzJzdmvmYN1GOXP+voXQD4MH WNmRl7nyq+Xy/FwXC2NukupFz1gxbnNJHOo60azYY2+tQtLzAOvYgolhtuZVC2uGFvKg /ZCXy7v444pAWBAKW3iXNUjcqA4dLFvQigENnkYS3n5FXyeey9HHZADa8Hv9nIEbHEMi lclUHZuOGTQhMV8V8QrF4W7MpvrDAHf2IeiDfYtygo1hTUhTT6yOOGpSWE13Qyikxnb6 Yh7A==
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:from:date :message-id:subject:to:cc:content-type; bh=lRK4ieNOLQgxsRlb7x2V3Z6GtpySWAKKeZqzedYQMbU=; b=joxY9DjNj8OeleZUdzF0129Trwk6sF+bRKKYdmj7Z7XsudP5Zb0RPljMvLkWvS9voU LKVmVzyiJOGhUZ/8ZZtNGrgDadSA0AXS1sFbUBL4Ek3eC+rnahtUA7NvNfdQQEBmZMM/ RuISJkHUJLlvR0lt275+FKt3UhwL/iaDCFSSPp6wD5n0GKbsw45GkLZr1cuQOF3lrK8P BIQMqq47odTVxqEMbyQIZvlKrv/txM5b238SVy8mdH2h7mBSrHSeTn7LqRd1YpWtBoje Z12v4MkNo0Lle6rYugm+B/NiCr/XoEQ/ILUgnO2iiwg/tJTt4x7CuLA+1OmOW3nzPP8D vBpg==
X-Gm-Message-State: ALoCoQkmmG7F2XiPrD6zSPteVWFO6jjyOKX+573a9URbe/Zv8swd/engOyKyxw88WqP7O5eLM43AZtvpq9DAe4zwMP6ag29DsQ==
X-Received: by 10.129.46.208 with SMTP id u199mr51771462ywu.129.1451577312754; Thu, 31 Dec 2015 07:55:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Thu, 31 Dec 2015 07:54:33 -0800 (PST)
In-Reply-To: <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> <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 31 Dec 2015 07:54:33 -0800
Message-ID: <CABcZeBMdSJXmZqvQkgJCKCAvQ2axkPXmfjSB9TKDPb_-ULTsZg@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=001a11408592178ba3052833ae4c
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mTyqjJRVGCDo37MTs8i4TZ4IY3M>
Cc: "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 15:55:15 -0000

I'm finding myself a bit unclear on the scenario people are concerned about.

It seems like there are two potential cases:

1. You have an implementation which already does some of the algorithms
we know are susceptible to THS-type attacks.
2. You have an implementation which only does the CFRG curves.

In the first case, if you are in a scenario where THS is relevant, then you
should be insisting on session hash for the existing algorithms and so it's
simplest to just always insist on session hash. And if you're failing to
do so, then it's not clear to me how having the CFRG curves be safe
here helps (it might be true, but I haven't convinced myself of it.)

In a previous thread, Brian suggested an implementation that was just
CFRG curves, so perhaps that's the scenario of interest? But in that case
you can just *only* implement session hash. Specifically, you insist on
negotiating the extension but only implement the session hash key
derivation,
rather than the normal key derivation, so there's not really a check to
omit [0].

Am I missing something?

-Ekr

[0] This is effectively how 1.3 behaves by just always requiring session
hash.





On Wed, Dec 30, 2015 at 10:54 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>