[TLS] Fixing TLS

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 12 January 2016 14:04 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2A5DC1B2A17 for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 06:04:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id o0RPqyvNoQiq for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 06:03:57 -0800 (PST)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24561B2A15 for <tls@ietf.org>; Tue, 12 Jan 2016 06:03:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452607437; x=1484143437; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yeWRc8KPSPwYpM6NUkI3lH2uV4d2AREe7RrMTSm6Lt8=; b=FQSsC2DBcjBqlLx/cbhkszybL6+n7ZU1z4uzifSIYd41Ud2hmeToKl6+ 2kkG7KXwI8pbXbmF9Avv9xOSQtGJ7Bjc+d0WqPfxET2qnBurabziB36Mr eUPTHhG/UDzrLFXd5q0susRMY32d55y0RKuiLDAiHuavjw0T4qJhPMdXo mz6qhMpDx1+l/OosaY0J3FSe229gQVJEb/PCImuoQVqEyXKPOlcWUJrYI 6vWdWOqQ9EYzFscsfUJ/QZsvYLlwFOHHtM8Hu0aKUyc3DMjyJcE8sslqt 5yo6t6bxS78MrONI0N5tU+iU7ZU/hKq2dzMRVgrp6c/sTaSAABqT/fhts A==;
X-IronPort-AV: E=Sophos;i="5.20,557,1444647600"; d="scan'208";a="62783138"
X-Ironport-Source: - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Jan 2016 03:03:54 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([]) by uxchange10-fe2.UoA.auckland.ac.nz ([]) with mapi id 14.03.0266.001; Wed, 13 Jan 2016 03:03:54 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: Fixing TLS
Thread-Index: AdFNQhHrFy3mVBx6TGiPN32I/iztzQ==
Date: Tue, 12 Jan 2016 14:03:53 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mFyJhsGGochLp5X18ZqcgcmdOoc>
Subject: [TLS] Fixing TLS
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: Tue, 12 Jan 2016 14:04:01 -0000

Martin's comment reminded me of the following that I've been meaning to

In a recent discussion among some crypto folks, the topic of what TLS 1.3
could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from
TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
centered around the fact that we already have lots of analysis done for TLS
1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
problems while being as compatible as possible with existing infrastructure.
So what this would do is take existing security analysis applied to TLS,

Bhargavan et al, "Proving the TLS handshake secure (as is)".

Brzuska et al, "Less is more: relaxed yet compatible security notions for key

Dowling et al, "Modelling ciphersuite and version negotiation in the TLS

Firing, "Analysis of the Transport Layer Security protocol".

Gajek et al, "Universally Composable Security Analysis of TLS".

Giesen et al, "On the security of TLS renegotiation".

Jager et al, "On the security of TLS-DHE in the standard model".

Krawczyk et al, "On the security of the TLS protocol".

(and probably several more) and use them to simplify TLS 1.2 to create an
improved TLS that leverages about 15 years of analysis, rather than creating
what's almost a new protocol based on bleeding-edge/experimental ideas,
mechanisms, and algorithms.

The discussion started out somewhat informally so by the time it got really
interesting it was too late to take notes, but I thought I'd try and recreate
the design points...

- Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-CBC +
  HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HMAC-
  SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for OCB
  instead of GCM as the AEAD if it were freely available).

- For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD as

- Get rid of the IPsec cargo-cult MAC truncation.

- For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #3) to
  allow verification (for those who don't have a copy of X9.42, it requires
  the same verification steps as FIPS 186 does).  Also, mix the hash of the
  DHE values into the computed premaster secret to protect against use of
  manipulated curves.

- RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-check
  done as encode-then-compare, which fixes all known padding-manipulation

- No compression or rehandshake.

- Replace the PRF with HKDF?  (No pressing need for this, but it would be part
  of the general cleanup).

Longer discussion points:

- The DHE/ECDHE parameters were a bit contentious.  For DHE the choice is
  between server-specified ephemeral parameters and IETF-blessed fixed ones.
  Arguments can be made either way, we had de facto IETF-blessed fixed DHE
  params in the form of the RFC 2409 ones, but that wasn't such a good idea.
  OTOH with ephemeral DHE params many implementations didn't check them, but
  then the spec never required any checking (or much of anything at all in
  regard to DHE use, which no doubt contributed to some of the dubious
  practices that have been found in the wild).  The situation wasn't helped by
  the use of the PKCS #3 representation, which the requirement to use the
  X9.42 form alongside the accompanying checks attempts to address.
- Similarly, for ECDHE the choice is between NIST and CFRG ones.  The CFRG
  ones are obviously better (for various values of better, see endless debates
  elsewhere), but some people will insist on only using something that's come
  from NIST (I'll reserve my opinion on that one, and wouldn't dream of
  stooping to phrases like "cargo cult protocol design"...).