Re: [TLS] False Start, DHE key exchange, and the Negotiated FF-DHE extension

Brian Smith <brian@briansmith.org> Tue, 23 December 2014 21:24 UTC

Return-Path: <brian@briansmith.org>
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 DBB731A9251 for <tls@ietfa.amsl.com>; Tue, 23 Dec 2014 13:24:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 BJeUQj17oe2Z for <tls@ietfa.amsl.com>; Tue, 23 Dec 2014 13:24:21 -0800 (PST)
Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576C71A924B for <tls@ietf.org>; Tue, 23 Dec 2014 13:24:18 -0800 (PST)
Received: by mail-oi0-f53.google.com with SMTP id g201so15339534oib.12 for <tls@ietf.org>; Tue, 23 Dec 2014 13:24:17 -0800 (PST)
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:date :message-id:subject:from:to:cc:content-type; bh=z4BGnDyo5KZDwBSXGbDAONENHL2ObsA0ilC1UNmDjxQ=; b=G/X+Wj1/OiFkSb/7v2BgWALdkjCD9fL8HhDtn6IOaKtRYxnHSDWccD7+bD0shFEHnK uGOGa8MpgAWXit+1+M31dBXOBfl66tjy182gaSjxdO17NevT8b2YLr0ozk/oS/bOPOXJ 1P5eTlgOZA0zRSoSczgmD86tpnsdYSzNJZxLVnkIo1VcmRtPxUk83R/Uv0gk0ek5bXSO YQLuBNHnvjQ2OsRsvruAVW/L078SuwHvaIicidne04d2ah4Hnfe6PCb2BKdtZACNaNxw 3Cmn9LMtyMVJVwmzvPASuAG88lNMqh+f8EIlhwz47rSaOmBa3l9wzOTA5uN0pO0UhdJJ Lwsg==
X-Gm-Message-State: ALoCoQkTAaJvgwOUlz2nW+8DQKyP4BrL56jm0grXh0HiQmnwxeVKEVWl/OUgLGi57dNNW00V+mGS
MIME-Version: 1.0
X-Received: by 10.182.97.226 with SMTP id ed2mr3154552obb.5.1419369857619; Tue, 23 Dec 2014 13:24:17 -0800 (PST)
Received: by 10.76.71.228 with HTTP; Tue, 23 Dec 2014 13:24:17 -0800 (PST)
In-Reply-To: <54946C20.6000404@fifthhorseman.net>
References: <CAFewVt4J4TdBa9tzzhmpU6rpwrbHXGpiSLeQNDUbQZEosFUtdg@mail.gmail.com> <5488ACB1.6090201@fifthhorseman.net> <CAFewVt6j0df+T0J0Z5mn15uFVfGvqqeVd=6p+ykzaGp12CO=jQ@mail.gmail.com> <54946C20.6000404@fifthhorseman.net>
Date: Tue, 23 Dec 2014 13:24:17 -0800
Message-ID: <CAFewVt67C0m_t88P5wG2eKGXN7bgB=pvHSoEFOxd80yj_xV10g@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KWGEM2aniDC7l8atd42vTLqVhh0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] False Start, DHE key exchange, and the Negotiated FF-DHE extension
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: Tue, 23 Dec 2014 21:24:23 -0000

Daniel Kahn Gillmor <dkg@fifthhorseman.net>; wrote:
> I've modified the ffdhe draft (as of -05) to include this guidance.
>
> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-05

This looks good. However, I think this text actually belongs in
draft-bmoeller-tls-falsestart, not draft-ietf-tls-negotiated-ff-dhe,
because (a) it applies even when the negotiated ff-dhe mechanism isn't
being used, (b) there are other tamperings besides ff-dhe that can
cause a downgrade in DHE strength, and (c) I think it is best to keep
all the false start stuff together when practical.

I think you can drop "and MUST offer at least one of these in the
initial handshake if they contemplate using the False Start protocol
modification." What the client actually offers doesn't matter as far
as False Start security is concerned; the only thing that matters is
what the server receives.

I think implementers will need more help in determining what is
"cryptographically strong," such as a suggested minimum key sizes and
suggested countermeasures against exploits targetting servers
misconfigured in a way that would permit small subgroup attacks or
other weak keys. For example, the recommendation could be to only do
false start when the server uses parameters in the FF-DHE registry,
which addresses both small keys and small subgroup attacks.

I think that some mention of the attacker controlling the choice of
ECDHE vs FF-DHE is also worth mentioning.

Cheers,
Brian