Re: [TLS] Version negotiation, take two

Andrei Popov <> Wed, 14 September 2016 19:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AECC212B453 for <>; Wed, 14 Sep 2016 12:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jHPWRja-07w6 for <>; Wed, 14 Sep 2016 12:02:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D244612B45F for <>; Wed, 14 Sep 2016 12:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xOZ5mRwTGJV3IMtIiskua0mHktDx/fGv5W0HBZ80ZH0=; b=WURzaUqdL5QcEvpwZ0TTzjWoGlWAYmMWotzekXO+MajOoEeHHxeUl86E3aa4s8N3D4fzEXgs5bB4xhUkDOnDEswRsyp1/fThNqe/IZ9PBZbqvw7XZLtxdrZfbxYbP5Pnu6epHugMVS5Z0JcD2/SKk7iSE0rmqspYCNmkBx0XFgY=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Wed, 14 Sep 2016 19:02:14 +0000
Received: from ([]) by ([]) with mapi id 15.01.0609.018; Wed, 14 Sep 2016 19:02:14 +0000
From: Andrei Popov <>
To: Hubert Kario <>
Thread-Topic: [TLS] Version negotiation, take two
Date: Wed, 14 Sep 2016 19:02:14 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:8::1d2]
x-ms-office365-filtering-correlation-id: d5f5a983-45e6-40e1-56dc-08d3dcd1a3da
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 6:DOt+RkS/PMuCfdTTN2NGS9SmavbPMA3S/QIqogvviQ3zurKaXpKIfmjMBc8odSlzOPA1gTxT/sPldUHOhG1ADxsc63QvYceaJv9fwz2dj3jDxSQmysiA/uXrKYxzI2qItxhW9JoeY0FuTcUSLEcCzzNTqlJASW7CSxYwTxSRLtlzaVsabj7+2G0JVnSge2pl0gIWZ4C4GP9zFtqQOifkKOKDaN0tqvEuIFfeWeUFwRyWyCooNIbPg/WXEca34tcy/KEuga18So7DE2Lf/5mMxPIyFFkFumD8HD8HRqCRAYDfE/4qp6TGFdmGAiPPaI51X7P1dO9m0YErdlpbzbET8A==; 5:v3fYb/fLk8nPaEF8nnCooUEfa30AnoXRE3Av6NRc1YK6mwT7Eub9smajfTEDR3tEVFxA22cIScXNcdIpFpmplyRrDZE0U5nFd1QzBtrJGcVGqVtLp7V3iF9Os8/aKVv9RQxgIXYim5OxSTIqH4sf5g==; 24:T3Z7yTk8OwGki0NVrznlk65V9juQrwjK/3IdpeYJLonJcPkgF2Bd+vXLT5x5xJ5kT2K2sisuiIARCfAiahFrKUyHVsWMt0dTd8mNStxtJI4=; 7:NOrZqrO8X2/7fhDsQrnMpnuNRDl6IpG5QWw4b34UA1E0ZRKwNUWkrMKFK8F49NanNlwO07aI72wVaB1Wzh9iVXgjsiOMWph6e2JGQp7Mg3ebdSm5xwWkifWs5rl9FaIfJA8QE51Cn2Z9FWVDPbZIVfAPcDmZL1Pe0tCQFoZwnV3S0Ovuj0/sJjaAh0bHkrG3dr6K/X86g8KPXrEYC4QkiWr5vSIoK86B9hG7huU4+BSCvPBT877+Z4LD7AkzxFUO
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0844;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844;
x-forefront-prvs: 006546F32A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(24454002)(189002)(13464003)(377454003)(2900100001)(189998001)(11100500001)(97736004)(76176999)(561944003)(50986999)(54356999)(8936002)(2950100001)(101416001)(81156014)(7736002)(7846002)(8676002)(5660300001)(87936001)(3660700001)(81166006)(122556002)(15974865002)(33656002)(74316002)(5002640100001)(77096005)(76576001)(305945005)(110136003)(86612001)(106116001)(86362001)(105586002)(10090500001)(68736007)(586003)(4326007)(8990500004)(3280700002)(106356001)(99286002)(92566002)(6116002)(10290500002)(10400500002)(2906002)(19580405001)(102836003)(19580395003)(7696004)(5005710100001)(9686002)(93886004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2016 19:02:14.1360 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Version negotiation, take two
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, 14 Sep 2016 19:02:31 -0000

Basically, I don't feel strongly about the switch to the proposed version negotiation mechanism. But if we are going to make this change based on the theory of having only one extension point and actively defending it, then we should probably follow the theory and send a separate TLS extension per TLS version.
> I don't think we should depart from the "highest mutually supported version" negotiation algorithm...
Correct, but it's not clear what represents "the highest" protocol version in the world where national TLS "standards" exist. Is country X-TLS (e.g. with integrated MITM support) a higher version than TLS 1.3? The server will make a choice based on the server's preferences. In a way, the proposed version negotiation mechanism makes it slightly easier to implement servers that support country X-TLS alongside IETF TLS versions.



-----Original Message-----
From: Hubert Kario [] 
Sent: Wednesday, September 14, 2016 11:03 AM
To: Andrei Popov <>
Cc: David Benjamin <>rg>;
Subject: Re: [TLS] Version negotiation, take two

On Wednesday, 14 September 2016 17:39:59 CEST Andrei Popov wrote:
> Do you mean a TLS extension code point per TLS version?

yes, e.g. if extension 0x00a0 is present assume TLSv1.3 support, 0x0121, TLSv1.4; same way EMS and MtE works

> One argument against this was that this makes it difficult to express 
> the client's prioritization of TLS versions, but IMHO arguably the 
> server should not care.

I don't think we should depart from the "highest mutually supported version" 
negotiation algorithm, any kind of preference in the client list is likely to cause additional problems - version misnegotiation

if client will want to advertise support for TLSv1.3 and TLSv1.5 but not
TLSv1.4 it will still be able to do that
> -----Original Message-----
> From: TLS [] On Behalf Of Hubert Kario
> Sent: Wednesday, September 14, 2016 9:40 AM
> To: David Benjamin <>
> Cc:
> Subject: Re: [TLS] Version negotiation, take two
> On Wednesday, 14 September 2016 16:17:50 CEST David Benjamin wrote:
> > Yes, we find list intolerance too---servers which only look at the 
> > second byte in a cipher suite, servers which forgot a default in 
> > their NamedGroup switch-case, servers which get confused on unknown 
> > HashAlgorithms, servers which require the final extension 
> > non-empty---but this is dramatically less than version intolerance.
> > It's usually within tolerable levels that we needn't resort to fallbacks.
> > 
> > The proposal switches from something which we know does not work to 
> > something new. Perhaps this new one will break too, but it is very 
> > similar to things that have worked before, and I am hopeful that 
> > GREASE will help.
> Was the option to do "one extension point = specific TLS version supported"
> discussed too? What arguments are there against it?
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web:
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic