Re: [TLS] Initial draft of DH-based key exchange
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 27 March 2015 16:17 UTC
Return-Path: <ilari.liusvaara@elisanet.fi>
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 4E99D1A03B3 for <tls@ietfa.amsl.com>; Fri, 27 Mar 2015 09:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 EhanodGY--iR for <tls@ietfa.amsl.com>; Fri, 27 Mar 2015 09:17:48 -0700 (PDT)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18CC71A00F1 for <tls@ietf.org>; Fri, 27 Mar 2015 09:17:47 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 28D8C699E6; Fri, 27 Mar 2015 18:17:46 +0200 (EET)
Date: Fri, 27 Mar 2015 18:17:46 +0200
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Message-ID: <20150327161746.GA28742@LK-Perkele-VII>
References: <CABcZeBNmufvfJ_2Nvw1YwvwGZ2u1=WvL45rPGJXARN1tAxOEfw@mail.gmail.com> <20150327150032.GA27825@LK-Perkele-VII> <D13ADBCE.43E69%kenny.paterson@rhul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <D13ADBCE.43E69%kenny.paterson@rhul.ac.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Ny_zYSP-tBVWE_-HAx6-Kn1JwQc>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Initial draft of DH-based key exchange
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: Fri, 27 Mar 2015 16:17:50 -0000
On Fri, Mar 27, 2015 at 03:27:54PM +0000, Paterson, Kenny wrote: > > The limitation of scope does not mean the papers are useless. As you write > above, one just needs to be wary of over-interpreting what they say. Well, not useless, but... There are different kinds of problems arising for over-interpreting security proofs: Take some protocol X that is designed to use TLS feature Y for purpose Z (e.g. SPDY used TLS-Extractor for channel binding). This can be outright broken (like the example is in TLS 1.2 without extensions). This calls for documenting limiations of various TLS features. And preferably not provoding "attractive nuisances". But that doesn't mean the features provoded won't be used in strange ways. More nasty case is if there is a security proof that some strengthening A is unnecressary given assumptions B (which seems quite broadly applicable). Then TLS removes A as "unnecressary". Except that using Y for Z breaks B and relies on A, so now X is insecure. This is obviously highly attractive for crypto sabotage projects. E.g. suppose TLS had renego-fix-like fix for resumption. Now remove session-hash because it is unnecressary given proper certificate authentication. Except now TLS-Extractor for channel binding is broken. This calls for being conservative with strengthening. -Ilari
- [TLS] Initial draft of DH-based key exchange Eric Rescorla
- Re: [TLS] Initial draft of DH-based key exchange Nikos Mavrogiannopoulos
- Re: [TLS] Initial draft of DH-based key exchange Eric Rescorla
- Re: [TLS] Initial draft of DH-based key exchange Hugo Krawczyk
- Re: [TLS] Initial draft of DH-based key exchange Ilari Liusvaara
- Re: [TLS] Initial draft of DH-based key exchange Eric Rescorla
- Re: [TLS] Initial draft of DH-based key exchange Hugo Krawczyk
- Re: [TLS] Initial draft of DH-based key exchange Salz, Rich
- Re: [TLS] Initial draft of DH-based key exchange Eric Rescorla
- Re: [TLS] Initial draft of DH-based key exchange Salz, Rich
- Re: [TLS] Initial draft of DH-based key exchange Dave Garrett
- Re: [TLS] Initial draft of DH-based key exchange Nikos Mavrogiannopoulos
- Re: [TLS] Initial draft of DH-based key exchange Nikos Mavrogiannopoulos
- Re: [TLS] Initial draft of DH-based key exchange Ilari Liusvaara
- Re: [TLS] Initial draft of DH-based key exchange Eric Rescorla
- Re: [TLS] Initial draft of DH-based key exchange Hugo Krawczyk
- Re: [TLS] Initial draft of DH-based key exchange Ilari Liusvaara
- Re: [TLS] Initial draft of DH-based key exchange Paterson, Kenny
- Re: [TLS] Initial draft of DH-based key exchange Eric Rescorla
- Re: [TLS] Initial draft of DH-based key exchange Ilari Liusvaara
- Re: [TLS] Initial draft of DH-based key exchange Russ Housley
- Re: [TLS] Initial draft of DH-based key exchange Hugo Krawczyk
- Re: [TLS] Initial draft of DH-based key exchange Eric Rescorla
- Re: [TLS] Initial draft of DH-based key exchange Hugo Krawczyk
- Re: [TLS] Initial draft of DH-based key exchange Ilari Liusvaara
- Re: [TLS] Initial draft of DH-based key exchange Ilari Liusvaara