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

Nikos Mavrogiannopoulos <> Tue, 24 September 2013 08:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B239021F9CCA for <>; Tue, 24 Sep 2013 01:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.422
X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zSpyDO1wVSt1 for <>; Tue, 24 Sep 2013 01:06:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c01::22f]) by (Postfix) with ESMTP id AAAB621F9C33 for <>; Tue, 24 Sep 2013 01:06:17 -0700 (PDT)
Received: by with SMTP id m14so2249561eaj.6 for <>; Tue, 24 Sep 2013 01:06:15 -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=jtY8CLX/7lRkYEpRoRr6MEH15/BUJcrCYxz3dFUZMsY=; b=c8mhxqoaT+KkkRxHtFOCUCkAhI2MyIWRh/sO7UVPknVfdXD0wW+woO0jfsegvitqOS OWwyqjyDSdgVhrRSHanNGRvc0lDzhb1g0qmC4aq2Ru+cp47n4JGjK/ep+18ceHJ/pHV2 lteV+RX+F7RoFvCXHxp1GPg0Sy1+x1guLSW9iFfh7u7FOYqd8w9scBNPAmn8NkDUVUlj fSOQr+oT5qwRW6Q7v93EBzFF2yvMhMHhfjGC6LQ998IDCK0QJa2BnzANy5GchhYFp/zu mhJN9E0p5CQYvkWtCT0nI0Q0IE9DZZMquoWujobFWWVGbAE+XJNAoWPPB/qsXjlWziLB iOIQ==
X-Received: by with SMTP id t46mr1892844eev.58.1380009975025; Tue, 24 Sep 2013 01:06:15 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id a1sm50555602eem.1.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 01:06:14 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <>
Message-ID: <>
Date: Tue, 24 Sep 2013 10:06:08 +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
To: Peter Gutmann <>
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: "<>" <>
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: Tue, 24 Sep 2013 08:06:36 -0000

On 09/24/2013 06:52 AM, Peter Gutmann wrote:

>> The innovate refers to how the current EtA proposal by Peter 
>> ignores all best practices in implementing EtA in protocols.
> You seem to be saying there that HMAC has security problems unless 
> it's truncated, which is something that AFAIK no other cryptographer 
> has ever noticed.  Perhaps you could clarify the weakness for the 
> list, and then consider publishing a conference paper on it.  It 
> sounds like an amazing breakthrough in the cryptanalysis of HMAC.

No I am not saying that and please do not twist my words to make a
point. I say that best current practice in protocols is to follow the
Preneel-van-Oorschot advice and do a truncation on the hash-based-mac to
prevent certain attacks (described in their paper). You do not follow
this advice on your proposal and you give no reasons why.

The only reason I've heard against truncation is some story you repeat
about IP headers space. Both the IPSec RFCs and people who participated
in the discussions say otherwise, and thus make your claim not convincing.

I may be wrong and truncation may not be needed, but you give not
convincing reasons why.

>> Existing EtA protocols like IPSec truncate the HMAC to avoid 
>> revealing the whole internal state of the hash algorithm.
> S/MIME doesn't truncate it.  TLS doesn't truncate it.  PGP (although 
> that doesn't really use a MAC, but still...) doesn't truncate it.

TLS doesn't truncate it because it uses the AtE mode which means it is
encrypted (and thus the simple hash-based-MAC attacks don't directly
apply). S/MIME and PGP aren't online protocols and use the MAC key for a
single message, thus several attacks don't apply to them.