Re: [TLS] Fixing TLS

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 13 January 2016 01:12 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722BA1AC7E7 for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 17:12:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFCja0zx6gxJ for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 17:12:16 -0800 (PST)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7801AC445 for <tls@ietf.org>; Tue, 12 Jan 2016 17:12:15 -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=1452647536; x=1484183536; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kX2QpgkzEfETrDKBKtjcXvoFaycEVp2JX7J+fFA0TMY=; b=QspJJxGn0CT7ExVkB4DTe8argX0KCoONipMXSBD828AoXkHD+VfsSOeU RLNoUVFacjxxRzBf6Xf7bur1r2H2C77dsaz/d9Gw6bm93WtKPRwVZT8/P niRrxo8KW3E5sYBOoNNVS4ucDf5QEXrm1W6wUF22ht9gwfjEAyectyXVU VDLSBtuqUziQMfyr/ujHadaAYhDCgC2KsSXBL0VJiNl/CMsmkEZzflY50 TJtRJVdpyI/dti+Q6DHCSm/5f6iRm4b8V0JEmyyYOOv8qKJ6h23cwXIwk i4+wPqBYlg1UXsJG96NGeUyd6l7UQBnj8x7d2vBkq69LQazhwlrJchp92 A==;
X-IronPort-AV: E=Sophos;i="5.22,286,1449486000"; d="scan'208";a="62866163"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Jan 2016 14:12:14 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Wed, 13 Jan 2016 14:12:14 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Yoav Nir <ynir.ietf@gmail.com>
Thread-Topic: [TLS] Fixing TLS
Thread-Index: AdFNQhHrFy3mVBx6TGiPN32I/iztzf//Ww+AgAFZaKY=
Date: Wed, 13 Jan 2016 01:12:12 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC727B@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz>, <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com>
In-Reply-To: <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
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/B_KDxt0ri4PEQCSetlLWqGdK6gU>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [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: Wed, 13 Jan 2016 01:12:18 -0000

Yoav Nir <ynir.ietf@gmail.com> writes:

>Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0)
>that this WG is working on right now, why?

Embedded devices and similar systems with long-term requirements.  Most of my
user base is embedded (or non-embedded equivalents, systems that need to run
in a fixed configuration for a very long time after they're deployed).  As
I've mentioned in an earlier post, the median point on the bell curve is
probably around TLS 1.0/1.1.  These are systems with an expected lifetime of
10-20 years or more, deployment of new versions moves slowly and carefully so
the less radical changes you need to make the better, and most importantly you
can't roll out patches every month or two when the next attack on TLS is
published.

To expand on this, I'll take Ilari Liusvaara's comments:

>Bleeding edge ideas? They essentially re-invented SIGMA, which is over 10
>years old. The basic framework for doing 0-RTT is the obvious one. The only
>new algorithm prsent since TLS 1.2 is HKDF, which is just 5 years old.
>
>So I don't see anything "experimential" ideas, mechanisms or algorithms in
>there

When SSLv3 was introduced, it also used ideas that were 10-20 years old (DH,
RSA, DES, etc, only SHA-1 was relatively new).  They were mature algorithms,
lots of research had been published on them, and yet we're still fixing issues
with them 20 years later (DH = 1976, SSLv3 = 1996, Logjam = 2015).

TLS 2.0-called-1.3 will roll back the 20 years of experience we have with all
the things that can go wrong and start again from scratch.  SIGMA, at ten
years old, is a relative newcomer to DH's 20 years when it was used in SSLv3,
but in either case we didn't discover all the problems with it until after the
protocol that used it was rolled out.  We currently have zero implementation
and deployment experience with 2.0-called-1.3 [0], which means we're likely to
have another 10-20 years of patching holes ahead of us.  This is what I meant
by "experimental, bleeding-edge".

What TLS 1.3-which-is-1.3 should be is an LTS version that's essentially
what's already out there with the bugs fixed, and where you've got a pretty
good chance that you won't be rolling out hotfixes every other month to patch
the newly-discovered-vulnerability of the month (which, in the case of most
things that aren't web browsers and servers, is more or less impossible to
do).

(Which also means that the requirements for it should include explicit "don't
use MD5, don't use keys < 1024 bits, don't precompute DH and reuse the
values", all the other obvious-but-apparently-not-obvious-enough stupid that's
turned up recently).

TLS 2.0-called-1.3 seems to be doing the same thing that HTTPS 2 did,
targeting the specialised requirements of web servers/browsers and ignoring
everything else.  The HTTPS 2 WG's response to this at the time was "let them
eat HTTP 1.1", so that you've now got HTTP-for-Google (2.0) and HTTP-for-
everything-else (1.1).  Is the TLS equivalent going to be "let them eat TLS
1.1"?

(General note: That one short post has generated an enormous amount of email
 off-list as well as on, for all those waiting for replies to private mail,
 please be patient, I'm working through it...).

Peter.

[0] This all feels somewhat biblical, "you are 2.0 son of 1.2, but you will be
	known as 1.3".