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