Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

Nikos Mavrogiannopoulos <> Mon, 23 September 2013 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3621921F9F99 for <>; Mon, 23 Sep 2013 06:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, SARE_URI_OEM=0.533]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 42jbsxExcDJT for <>; Mon, 23 Sep 2013 06:53:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c00::22b]) by (Postfix) with ESMTP id 21DB421F9FB5 for <>; Mon, 23 Sep 2013 06:53:27 -0700 (PDT)
Received: by with SMTP id e52so1761570eek.16 for <>; Mon, 23 Sep 2013 06:53:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=DPH4YysGyVWBT/CF8Z6RbcytUYX8MH407a7XO1Vvp0Y=; b=ljqq0kwQpXsuSgSmnN/iuOPjpJyYU7lDVOSywMFH8ZGfLURajyPrJ6jKWPPzCO7x0p w6LOj1CD5OkZ+2EettnR/uFFWZtIXBwwsIQsfpYq4ScRFSfDuF3FA6vbMUySnYSSOo+d 8LsXbcC0+nN+d4WUO0RhjltmGp/Pq1LsYssRdzde2d41X5IUYDHSVBHcwrdNnl53igZ9 Z47W5bc8T68IRkVHv2YJDbkNLDTV7DCOJLwDf9jOmk5IQBzYpzwtJeiJI0x3koktW+7S Kg/ZOvQenXIlXFXJea9XF8ss1Kn1YxpdpB9Rm4W4H3ZmSKsYX2QN6zq8ewV3Pl5qjjsR qfFA==
X-Received: by with SMTP id y49mr3855207eel.50.1379944407208; Mon, 23 Sep 2013 06:53:27 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id a1sm42327472eem.1.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 06:53:26 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <>
Message-ID: <>
Date: Mon, 23 Sep 2013 15:53:21 +0200
From: Nikos Mavrogiannopoulos <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Christian Kahlo <>, 'Team Neuer Personalausweis' <>,
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-Mailman-Version: 2.1.12
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, 23 Sep 2013 13:53:29 -0000

On 09/23/2013 02:50 PM, Christian Kahlo wrote:

>>> I'm not saying that we don't approve new algorithms and ciphers
>> suites. I'm
>>> saying we need ETM as well.
>> What we need is a solution for the issue with the unauthenticated
>> padding in the CBC ciphersuites. ETM is not the only way to solve the
>> issue, and even if it is used, it would be highly recommendable to
>> follow the existing good practices. TLS isn't the first protocol to use
>> this mode, thus there isn't a need to innovate.
> maybe you want to read
> and
> Both mentioned within this thread:
> encrypt-then-mac

Have you actually read the papers you mention? For example have you seen
theorem 2 of the second paper? The issue is with the unauthenticated
padding used in TLS not AtE. There are only philosophical advantages of
EtA over AtE when the latter is implemented properly (i.e., as not in
TLS). Today we have more clues on the issues of AtE than it was at the
time TLS was designed.

> Please tell us which protocols are still using Mac-then-Encrypt today
> without running into any security trouble (esp. chosen ciphertext
> attacks). MtE is considered as a design fail by many researchers.

TLS with stream ciphers. It is authenticate-pad-then-Encrypt that has
issues, please check the literature more carefully.

> As we discussed earlier AEAD might be a solution, but AEAD is not the
> only one. I would encourage everbody to also have a look into
> ISO7816-4 secure messaging. That's the way most electronic ID cards,
> electronic purse cards, credit cards, small HSMs, etc. do communicate.
> And now think about that there's a reason for that it's an EtM-
> scheme.
> Sorry, your attitude "there isn't a need to innovate" sounds
> somewhat unfamiliar with cryptographic primitives to me.

Please read my mail again. The innovate refers to how the current EtA
proposal by Peter ignores all best practices in implementing EtA in
protocols. Existing EtA protocols like IPSec truncate the HMAC to avoid
revealing the whole internal state of the hash algorithm. The
Preneel-van-Oorschot paper referenced previously in the thread gives a
detailed treatment of the issues (admittedly HMAC was designed to
discourage these attacks, but being conservative is a good design practice).