Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

Nikos Mavrogiannopoulos <> Fri, 29 November 2013 23:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 475251AE066 for <>; Fri, 29 Nov 2013 15:22:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.603
X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pzb2iQBMKJ1e for <>; Fri, 29 Nov 2013 15:22:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 878B11ADFFE for <>; Fri, 29 Nov 2013 15:22:47 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id rATNMfp6026133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Nov 2013 18:22:41 -0500
Received: from [] ( []) by (8.14.4/8.14.4) with ESMTP id rATNMcP0023394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 18:22:39 -0500
Message-ID: <1385767358.5937.18.camel@aspire.lan>
From: Nikos Mavrogiannopoulos <>
To: Juho =?ISO-8859-1?Q?V=E4h=E4-Herttua?= <>
Date: Sat, 30 Nov 2013 00:22:38 +0100
In-Reply-To: <>
References: <> <>
Organization: Red Hat
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on
Cc: "<>" <>, Peter Gutmann <>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Fri, 29 Nov 2013 23:22:49 -0000

On Fri, 2013-11-29 at 23:38 +0200, Juho Vähä-Herttua wrote:

> > I also dislike (a) making a change to SSLv3/TLSv1.0
> GenericBlockCipher > processing, but (b) leaving the predictable IV
> exploited by BEAST > unfixed, and essentially creating two seperate new
> GenericBlockCipher PDUs, > rather than just a single one for all that
> fixes all known problems.
> Ok, this is a valid point I have missed in the discussion. TLSv1.1 is a
> very small update to TLSv1, so one could always ask why is it not
> supported better. Is the version number change somehow scary to people?

At the time of TLS 1.1, it was not known that a big number of TLS
implementations were not able to properly do TLS version negotiation and
handle gracefully a TLS version downgrade. In gnutls after we added TLS
1.1 we realized that enabling it would make the library unable to talk
to several (prominent at the time) servers. So I presume that this
compatibility issue and the fact that there was no popular demand (which
occurred only after the media hype with the beast attack), very few
bothered to implement it.

> That being said, I would support adding explicit IV to the
> encrypt-then-mac spec, unless we have reason to think it would slow
> down adoption. Personally I don't see how a block of random numbers
> would be too difficult.
> Nikos, do you think you should combine the pad and the IV in the
> defined structs? It would fix the BEAST attack at the same time even in
> SSLv3...

Certainly the draft (or any other fix) could require that the TLS 1.1
explicit IV in CBC ciphersuites is used when used with TLS 1.0 or
earlier (although, that would make the protocol messier, it looks it
provides quite some advantages).

> > MAC in the clear is only safe when the MAC algorithm is sufficiently
> > close to perfect.  We know painfully well that our hash algorithms >
> are *not* perfect, so I'm against taking chances, in particular > for
> the GenericBlockCipher PDU.
> But in a VERY hypothetical case where attacks to some HMAC is found, we
> would have no idea how it affects TLS without further analysis, using
> it in a standard way would at least give more information about what is
> broken. And of course HMAC is not just a hash.

Contrary to popular opinion on this list AtE is a standard way of
operation with no flaws known unless used with an unauthenticated pad
(as in TLS). When SSL 3.0 was designed AtE was believed to be the
conservative approach comparing to EtA.