Re: [TLS] A la carte handshake negotiation

Nico Williams <nico@cryptonector.com> Sat, 27 June 2015 01:40 UTC

Return-Path: <nico@cryptonector.com>
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 D5D9B1B2AD1 for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 18:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.066
X-Spam-Level:
X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 PekShHPbQLYR for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 18:40:37 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2721ACD78 for <tls@ietf.org>; Fri, 26 Jun 2015 18:40:37 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 1ED7321DE57; Fri, 26 Jun 2015 18:40:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=RRx86z0j6DYRQf SkUyDDJ68/E6A=; b=FLrHPZcddg8oWjHvEF94Xy94lBioMUVoQ51T1aLSUXZYdr Yo2GZDGI5o7QwS3EhBJtzc6l5A/jwZJwiuRPQQgNHGX5UGp0YjRItJvUqBXvixTC TyjFNiw0fcCuMefSkRL+kk/tNUE2Noqdxucg5qS76nhVXfWjDcSprWSnLGnyA=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPA id A553F21DE55; Fri, 26 Jun 2015 18:40:36 -0700 (PDT)
Date: Fri, 26 Jun 2015 20:40:35 -0500
From: Nico Williams <nico@cryptonector.com>
To: Dave Garrett <davemgarrett@gmail.com>
Message-ID: <20150627014034.GL6117@localhost>
References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <CAF8qwaAkBAXDkhd3zU=uO1t-dv7iu0bhb9bH28JHROrWp98SEA@mail.gmail.com> <201506261924.24454.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201506261924.24454.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/F248bNHYPsFT9bRzccTa_lca3gI>
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 01:40:39 -0000

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.

> Not a bad route, but requires defining a pile of new suites.

We wouldn't change any of the details of the symmetric parts of the
cipher suites.  It'd be easier to keep track of things if we do this.

Nico
--