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

Henrick Hellström <> Tue, 29 March 2016 01:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2125312D0AC for <>; Mon, 28 Mar 2016 18:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yhb3j5UvNK3e for <>; Mon, 28 Mar 2016 18:23:15 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 265FE12D0B8 for <>; Mon, 28 Mar 2016 18:23:14 -0700 (PDT)
X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04
Received: from (unknown []) by (Halon Mail Gateway) with ESMTP for <>; Tue, 29 Mar 2016 03:23:11 +0200 (CEST)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 939FAC93DD for <>; Tue, 29 Mar 2016 03:23:18 +0200 (CEST)
References: <> <> <>
From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Tue, 29 Mar 2016 03:23:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
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: Tue, 29 Mar 2016 01:23:18 -0000

On 2016-03-18 09:57, Peter Gutmann wrote:
> 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.

Indeed. For instance, if VM reset attacks are a concern, GCM is arguably 
a worse option than CBC, in particular if the CBC record IV generation 
can be made to be random even in the case of a VM reset attack.