Re: [TLS] Thoughts on Version Intolerance

Hanno Böck <> Wed, 20 July 2016 10:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B093012DAD1 for <>; Wed, 20 Jul 2016 03:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W8WW-Q3tyEQU for <>; Wed, 20 Jul 2016 03:01:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84C1212DA51 for <>; Wed, 20 Jul 2016 03:01:36 -0700 (PDT)
Received: from pc1 ([::ffff:]) (AUTH: LOGIN, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by with ESMTPSA; Wed, 20 Jul 2016 12:01:34 +0200 id 0000000000000029.00000000578F4BFE.000079B8
Date: Wed, 20 Jul 2016 12:01:25 +0200
From: Hanno Böck <>
Message-ID: <20160720120125.43f61155@pc1>
In-Reply-To: <>
References: <20160718130843.0320d43f@pc1> <> <>
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary=""
Archived-At: <>
Subject: Re: [TLS] Thoughts on Version Intolerance
X-Mailman-Version: 2.1.17
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, 20 Jul 2016 10:01:44 -0000

On Wed, 20 Jul 2016 11:20:46 +0200
Hubert Kario <> wrote:

> so it looks to me like while we may gain a bit of compatibility by
> using extension based mechanism to indicate TLSv1.3,

Just quick: This was discussed yesterday, David Benjamin had an
interesting proposal, but it was largely met with resistance. So from
the WG discussion yesterday I had the impression that we will most
likely stay with the existing clienthello version mechanism. While that
will cause us more trouble, it's probably the cleaner option anyway. So
we definitely should continue investigating version intolerance and
tell people to fix their stuff.

I'm now also collecting some data and have some preliminary
suspicion on affected devices. My numbers roughly match yours that we
are in the more or less 3% area of 1.3 intolerance.

Hanno Böck