Re: [TLS] Fixing TLS

Hubert Kario <> Wed, 13 January 2016 12:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 565E01ACDC2 for <>; Wed, 13 Jan 2016 04:44:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M23ps722E01Y for <>; Wed, 13 Jan 2016 04:44:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CAE4E1ACDC0 for <>; Wed, 13 Jan 2016 04:44:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id 744D78E257; Wed, 13 Jan 2016 12:44:28 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id u0DCiQD2009556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2016 07:44:28 -0500
From: Hubert Kario <>
To: Peter Gutmann <>
Date: Wed, 13 Jan 2016 13:44:26 +0100
Message-ID: <>
User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2252725.GHKkY8NAg0"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Fixing TLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jan 2016 12:44:30 -0000

On Wednesday 13 January 2016 12:32:05 Peter Gutmann wrote:
> Hubert Kario <> writes:
> >So lets not repeat those mistakes
> Exactly, there are more than enough new ones for 2.0-called-1.3 to
> make that we don't (necessarily) have to repeat existing ones
> (although I'm sure we will in some cases).
> And that's exactly my point, we're throwing away 20 years of refining
> TLS 1.x and more or less starting again with 2.0-called-1.3, with a
> whole new set of mistakes to make.  I really don't want to spend the
> next 20 years patching all the holes that will be found in
> 2.0-called-1.3, I've already had enough of that for the 1.x version.

The only thing I saw in the "TLS 1.2.1" proposal that isn't already 
available is the longer Finished hash and a new signature type. 
Something that an extension can easily fix, rest is just a matter of 
setting a policy *and following it* with respect to used extensions and 

If you want to patch it up like this, please do. But TLS 1.3 fixes more 

> TLS needs an LTS version that you can just push out and leave to its
> own devices, for the same reason that other products also have LTS
> versions, that lots of people have better things to do with their
> life than playing bugfix whack-a-mole for the duration of it.

You're asking for impossible. The problems mentioned were not introduced 
into the protocols intentionally to make them obsolete, they are there 
because they weren't seen as big enough to fix. That's the mistake I say 
we should not repeat - "no issue left behind, no matter how small".
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic