Re: [TLS] Deployment ... Re: This working group has failed (Martin Rex) Mon, 18 November 2013 19:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8E6A41ADFB9 for <>; Mon, 18 Nov 2013 11:25:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VTLKPcNQl-J3 for <>; Mon, 18 Nov 2013 11:25:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 316191AE0BC for <>; Mon, 18 Nov 2013 11:25:46 -0800 (PST)
Received: from by (26) with ESMTP id rAIJPWEM015597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Nov 2013 20:25:32 +0100 (MET)
In-Reply-To: <>
To: Andrei Popov <>
Date: Mon, 18 Nov 2013 20:25:32 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Cc: " list" <>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
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: Mon, 18 Nov 2013 19:25:48 -0000

Andrei Popov wrote:
> Yes, the percentage if servers that can't handle TLS1.2 or gracefully
> negotiate a lower protocol version is diminishing, but very slowly.

Unfortunately, I've seen a new (government mandated) Web Service usage
scenario deployed in 2013 where the hardware SSL/TLS accellerater that
is being used is TLS version intolerant to TLSv1.1 and TLSv1.2.

We really need to get rid of the dependency on ClientHello.client_version
being { 0x03, 0x03 } to use protocol features that can be implemented
with fairly little effort in TLSv1.0, thereby obviating the need
for reconnect fallbacks in clients -- a "feature" that most programmatic
TLS clients do not have, and that is susceptible to downgrade.

> From my perspective, enabling TLS1.2 by default is necessitated
> primarily by security and performance considerations (e.g. a chance
> to negotiate AES_GCM instead of RC4).

The interoperability problems from sending
ClientHello.client_version { 0x03,0x03 } are to serious and significant
to ignore, and the kludges (reconnect fallbacks) are to cumbersome
for most apps.

The _correct_ approach would be to publish how to use GenericAEADCipher
record layer PDU and AES-GCM / AES-CCM with **ANY** version of TLS and
remove the braindead "must not send this ciphersuite with client_version
less that TLSv1.2" from the AES-CCM and AES-GCM documents.

rfc5746 deployed with significantly less interop problems than both
TLSv1.1 (rfc4346) and TLSv1.2 (rfc5246).

> However, for web browsers, enabling TLS1.2 by default means one more
> step in the sequence of (insecure) reconnect attempts with lower
> protocol versions.

Rather than bulding such kludges into Browsers, the implementers
should have come to the TLS WG help working on changes to TLS that
will make all desired TLS features work in a more backwards compatible
fashion than through kicking "client_version" / "protocol_version" fields.