Re: [TLS] WGLC: draft-ietf-tls-session-hash

Adam Langley <agl@imperialviolet.org> Mon, 24 November 2014 10:36 UTC

Return-Path: <alangley@gmail.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 386781A1EEF for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 02:36:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
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, FREEMAIL_FROM=0.001, SPF_PASS=-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 KeyV8ArZiDEJ for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 02:36:24 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7AEC1A1EFC for <tls@ietf.org>; Mon, 24 Nov 2014 02:36:23 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id l4so1530830lbv.39 for <tls@ietf.org>; Mon, 24 Nov 2014 02:36:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=12LTfRv94HTGhKzBAHxE2G+L0ZRVarLwlbq3jm5HEXI=; b=KtGVMwjC30omwHzjquUjaaUBuSqvBOL9i19ZdsBhEC4KfUtVdxytDSffzwfWdLMS1I vseXCWWDNJrrZ5gyHehiJOT+rhSRdt5T7s0dU/QkjN4Zn2DEOxr9i8qIEWxVBJiK/m4y xwdvdlO4xU5ZEWDe+tTmsEPTJuNv50JCTvvi15dx1ZKPdDcmKev4iRNdCpD5ycCxUV7W azuZ9aXcGxvAFQpVQdI0YsZaKY+CJ2nrSar7E8YTJuiKzdIl58h4XxDy4/JO/vBMzs0h UqjtGaX6vN/HXKRT8TulA4xW+Ld61PDrB1bTHX5YHdcxpJdYXzyg9EIiPOi+f8XyQ+mM iV1Q==
MIME-Version: 1.0
X-Received: by 10.153.11.133 with SMTP id ei5mr19752015lad.75.1416825382279; Mon, 24 Nov 2014 02:36:22 -0800 (PST)
Sender: alangley@gmail.com
Received: by 10.112.241.103 with HTTP; Mon, 24 Nov 2014 02:36:22 -0800 (PST)
In-Reply-To: <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com>
References: <E3E12F78-101D-4BA8-9EFB-53C24362066E@ieca.com> <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com>
Date: Mon, 24 Nov 2014 02:36:22 -0800
X-Google-Sender-Auth: DJXrF-LJa98MRNx-3j_vbCjzATs
Message-ID: <CAMfhd9V8fxZkmdMBg-h1v5McgPe8Kfxo0wVh3c5H+bvRxs3xug@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_QcEru8EqLilwcIb6ffELmTzKW8
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash
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: <http://www.ietf.org/mail-archive/web/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: Mon, 24 Nov 2014 10:36:25 -0000

On Mon, Nov 24, 2014 at 12:44 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> The first sentence says that (EC)DHE ciphersuites are also vulnerable with explicit params. The last sentence talks of "other key exchanges", which in practice means DHE or ECDHE with named groups or curves. But that lower case “may” is content-free. Suppose a new server supports only ECDHE ciphersuites with named curves (there are some popular web sites that do this today), does it also need the session hash extension? This is not covered in either the introduction or the security considerations.

I think that last sentence was roughly aimed to mean: "other key
exchanges (i.e. SRP, Kerberos, PSK), and future ones, may also have
properties that allow for this attack. We're not going to worry about
analysing them and instead will solve the problem in general (we
hope)."

But clearly some work tweaking is called for as that's evidently not
completely clear.

> Second issue: The draft does not say whether a server should include the extension in a resumed session. The extension has no effect (as section 5.1 says), but it should be specified one way or the other. I would go for the less meaningless bytes option.

Sure, let's say that the server SHOULD NOT echo it. (And I'll make a
note to check my implementations for that.)

> Third issue: Why can’t an attacker disable this protection by simply omitting the extension from both its ClientHello and ServerHello?

Writing this down might be called for too. In practice, I'm
implementing it so that calls to get tls-unique values and the like
will fail on resumed connections where the original session did not
use this extension.


Cheers

AGL