Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Peter Gutmann <> Fri, 18 March 2016 08:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B40012D795 for <>; Fri, 18 Mar 2016 01:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DqL0q5SSb-HD for <>; Fri, 18 Mar 2016 01:57:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8438012D769 for <>; Fri, 18 Mar 2016 01:57:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1458291449; x=1489827449; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Za+OVcmZTTnn/0TnYizueoT5k1e1H8aWoYD9tslnoi4=; b=PqpnBVmGWfQNGIa7QaEgYF4vJotlN3aeYv46pCtxnP1dFgT/ivl+PcqP KmjozhOfr8NHSG9Eyc6elv++cmFihSbN0csRcIzwHsjhOID3NY/V9ALdM kVUXxxglVX+/XFTAZXqUh5CiMQxveau2dEi3z5P5/cnU9jzs0gHnC3YfF tS294+yTEPYgN75QmyLCNChQkCdknhkcENM4sLsKgCKtOGP2WdX/D3bP+ tugIi39/llQLB3dW6wnN+mIeHMKyYFOElfL2YVAYwtrXnFEBqHoPzR7h0 wBDDO3iE7SeLn/F1lvtmLVxEeYCFacZt/lbCji6yNjiD9NTW9PAv5ioud g==;
X-IronPort-AV: E=Sophos;i="5.24,354,1454929200"; d="scan'208";a="75063931"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 18 Mar 2016 21:57:27 +1300
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Fri, 18 Mar 2016 21:57:27 +1300
From: Peter Gutmann <>
To: Watson Ladd <>
Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted
Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2ev//TwgAgAOYO3A=
Date: Fri, 18 Mar 2016 08:57:26 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
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: Fri, 18 Mar 2016 08:57:35 -0000

Watson Ladd <> writes:

>As written supporting this draft requires adopting the encrypt-then-MAC
>extension. But there already is a widely implemented secure way to use MACs
>in TLS: AES-GCM. 

This is there as an option if you want it.  Since it offers no length hiding,
it's completely unacceptable to some users, for example one protocol uses TLS
to communicate monitoring commands to remote gear, they're very short and
fixed-length, different for each command, so if you use GCM you may as well be
sending plaintext.  In addition GCM is incredibly brittle, get the IV handling
wrong and you get a complete, catastrophic loss of both integrity and
confidentiality.  The worst that happens with CBC, even with a complete abuse
like using an all-zero IV, is that you drop back to ECB mode.

>Likewise, this draft modifies the way the master secret is computed, despite
>a widely implemented different solution to the problem, namely the EMS triple
>handshake fix. 

Firstly, that solves an entirely different problem, and secondly I don't
recall ever seeing EMS support in any embedded device, it may be widely
implemented in Windows and OpenSSL but I don't know how much further it goes.

>The use of uncompressed points makes off-curve attacks much easier than with
>compressed points. 

Everything uses uncompressed points at the moment without any problems, and
compressed points are patented.

>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more extensively
>analyzed then TLS 1.2. 

As the rationale points out, the mechanisms in SSL were also very heavily
analysed when they were released.  It didn't protect the protocol from 20
years of subsequent attacks, which we've leared about over those 20 years of
implementation and deployment experience.  With TLS 1.3 we have zero
implementation and deployment experience.  Do you really believe there will
never be any attacks on it after it's rolled out?