Re: [TLS] A la carte handshake negotiation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Sat, 27 June 2015 08:09 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 313E31B321F for <tls@ietfa.amsl.com>; Sat, 27 Jun 2015 01:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 l_N_sb9hqZSa for <tls@ietfa.amsl.com>; Sat, 27 Jun 2015 01:09:31 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0609F1B321E for <tls@ietf.org>; Sat, 27 Jun 2015 01:09:31 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id BA250188E5D; Sat, 27 Jun 2015 11:09:28 +0300 (EEST)
Date: Sat, 27 Jun 2015 11:09:28 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Nico Williams <nico@cryptonector.com>
Message-ID: <20150627080928.GA7886@LK-Perkele-VII>
References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <CAF8qwaAkBAXDkhd3zU=uO1t-dv7iu0bhb9bH28JHROrWp98SEA@mail.gmail.com> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20150627014034.GL6117@localhost>
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/FyU7UhlEmhqyD1WvgvuQ63Y9vb4>
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: Sat, 27 Jun 2015 08:09:33 -0000

On Fri, Jun 26, 2015 at 08:40:35PM -0500, Nico Williams wrote:
> On Fri, Jun 26, 2015 at 07:24:24PM -0400, Dave Garrett wrote:
> > On Friday, June 26, 2015 06:40:15 pm David Benjamin wrote:
> > > Amusingly, if we use the same namespace but use completely non-overlapping
> > > values, it might be safer to put the 1.3 ciphers *after* the 1.2 ones.
> > 
> > This is sort of a variation of one of the ideas much earlier in the
> > discussion. The idea was to create new cipher suites for TLS 1.3+ and
> > cut off support for old suites in new versions. This would let us name
> > them in a less confusing manner, e.g.:
> > TLS2_E_CERT_WITH_AES_128_GCM_SHA256
> > TLS2_E_ANON_WITH_AES_128_GCM_SHA256
> > TLS2_E_PSK_WITH_AES_128_GCM_SHA256
> > TLS2_S_PSK_WITH_AES_128_GCM_SHA256
> > (where 'E' indicates ephemeral and 'S' indicates static or symmetric-only)
> 
> We could do even better: stop cartesian products altogether.
> 
>   TLS_SRV_AUTH_NONE (anon)
>   TLS_SRV_AUTH_PKIX (certs)
>   TLS_SRV_AUTH_PSK  (also authenticates the client)
> 
>   TLS_KEX_DH
>   TLS_KEX_ECDH
>   TLS_KEX_KEY_TRANSPORT (encryption to the server's RSA pubkey)
> 
>   TLS_ENC_AES_128_GCM_SHA256 (the hash is for the handshake, but has to
>                               match the symmetric encryption suite's
>                               strength)
>   TLS_ENC_AES_256_GCM_SHA512
>   ...
> 
> Key exchange, authentication, bulk+hash.

One can't really decouple authentication and key exchange cleanly,
especially because of PSK (KEX+Auth sets key exchange shape).

Also, DH and ECDH (and perhaps some other things) do unify to GDH.

Also, one way to do PRF-hash replacement would be to define sets of
PRF-hashes, and have the symmetric algorithm pick algorithm from
that set.

E.g. SHA-2: SHA-256/SHA-384/SHA-512
     BLAKE2B: BLAKE2B-256/BLAKE2B-384/BLAKE2B-512

Then YYY_HASH256 + SHA2 -> SHA-256, YYY_HASH384 + SHA2 -> SHA-384,
YYY_HASH256 + BLAKE2B -> BLAKE2B-256, YYY_HASH384 + BLAKE2B-384
And so on.



-Ilari