Re: [TLS] A la carte handshake negotiation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Wed, 22 July 2015 09:31 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 B8D901AC3E9 for <tls@ietfa.amsl.com>; Wed, 22 Jul 2015 02:31:48 -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 Q6quHHP4m6Ru for <tls@ietfa.amsl.com>; Wed, 22 Jul 2015 02:31:46 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8735E1A887C for <tls@ietf.org>; Wed, 22 Jul 2015 02:31:45 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 3A015901D9; Wed, 22 Jul 2015 12:31:43 +0300 (EEST)
Date: Wed, 22 Jul 2015 12:31:43 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20150722093143.GA7186@LK-Perkele-VII>
References: <201506111558.21577.davemgarrett@gmail.com> <CABcZeBPJUXdhER3qLiq0e_wK4bxCxw6D+Oq+3ZFXGeo6Bn1sXw@mail.gmail.com> <201507191622.47921.davemgarrett@gmail.com> <201507212202.21120.davemgarrett@gmail.com> <CAJU8_nUHMQAMKs15uVz=wsO4VnDp+chKPP36Q7QeR8hhD5vorQ@mail.gmail.com> <CABkgnnX_-1UO75xPyMOYJh2xoCU20Uee97YtB0t0Sae70ZfYFw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABkgnnX_-1UO75xPyMOYJh2xoCU20Uee97YtB0t0Sae70ZfYFw@mail.gmail.com>
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/UYdgyUtYTMZMQg7PDW6PRs-Y8GI>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] A la carte handshake negotiation
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: Wed, 22 Jul 2015 09:31:48 -0000

On Wed, Jul 22, 2015 at 02:16:43AM -0700, Martin Thomson wrote:
> On 22 July 2015 at 01:50, Kyle Rose <krose@krose.org>; wrote:
> > I'd like to see the bits of the cipher suite associated entirely with
> > ephemeral data tied together roughly by security margin
> 
> I've seen this argument several times, but there are reasons why you
> might want a non-homogenous strength profile.
> 
> The argument for consistency is appealing, but given that the design
> of TLS is historically[1] vulnerable to the weakest *supported*
> algorithm as opposed to the weakest *used* algorithm, I am not
> concerned about ensuring consistency.

Furthermore, comparing the strengths of kex, auth, ciphering and
PRF seems like comparing apples, orangles, pears and kumquants.

Even if the nominal strengths are the same, the scaling of strengths
is going to be different (e.g. the quadric vs. linear sub-treshold
scaling for ECDH vs. symmetric).

> > The one thing I'm having trouble pinning down is PSK. I fear it's not
> > a separate dimension, because it replaces both signature and KEX.
> 
> Yes, this is a problem.  I like to think of PSK as KEX with null auth.

I think TLS has currently four non-obsolete key exchanges:
- GDHE_CERT
- GDHE_PSK
- GDHE_anon
- PSK


(I couple things here because I think that decoupling those would
lead to unacceptable interop problems).


-Ilari