Re: [TLS] padding bug

Nikos Mavrogiannopoulos <nmav@gnutls.org> Tue, 24 September 2013 12:17 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B23511E811E for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 05:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Level:
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-lUnx0ZCDbR for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 05:17:34 -0700 (PDT)
Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id B309F11E8110 for <tls@ietf.org>; Tue, 24 Sep 2013 05:17:33 -0700 (PDT)
Received: by mail-ea0-f179.google.com with SMTP id b10so2395005eae.24 for <tls@ietf.org>; Tue, 24 Sep 2013 05:17:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=qCsuUgsQqbiMeAEUhysvRmjwi1gFC6Ero1awl4iEf0Y=; b=QVpOBTH49rYDwNKWRGGBPf6ELKa/6CntUUvUxmRdkoFZWDzUWzp+LVGKGFQh0Mmef0 YYMSxhRaezGAMRBM5ZTv7/Ll23U0bk1bApNJNT42a2cAbYrsQkbfkwdP3XSJu53tE+UL B6Vfpzq4nV6/67HdTALp5ysp5/Uiy+MjSs1ttpMuJ6tRlef2A6GioIQDsR62F/y5kRPh ZmUNgR02Y3PteBYVMcIGc9HE1SN6Bv4JrVccNTVylv4mXL42F/igcHWbcCzjBnqD2cLV qrkHdv9vPMv6RDKTOd03Ea5s2beBX1ogfNurp3apf1LBF85yHgGsNrzuAFsQwvVgS8vj s+xQ==
X-Received: by 10.14.37.4 with SMTP id x4mr46284784eea.16.1380025052830; Tue, 24 Sep 2013 05:17:32 -0700 (PDT)
Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id v8sm2564787eeo.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 05:17:32 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <524182EC.80505@gnutls.org>
Date: Tue, 24 Sep 2013 14:17:48 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: Ben Laurie <benl@google.com>
References: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz> <524148C3.7090709@gnutls.org> <CABrd9SRHheYhNjcbKosaEASfJ6EvZtN93HaLG=Cvzn_1ohKFgw@mail.gmail.com> <524176EA.3090401@gnutls.org> <CABrd9SQQ0Ormyx=wjnXO+Z-Zo52x_tYV7R4XuLMgbyHf2X7H=w@mail.gmail.com>
In-Reply-To: <CABrd9SQQ0Ormyx=wjnXO+Z-Zo52x_tYV7R4XuLMgbyHf2X7H=w@mail.gmail.com>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2013 12:17:34 -0000

On 09/24/2013 01:40 PM, Ben Laurie wrote:

>>> Can you provide a reference for your claim?
>> I believe we make circles. I previously referenced IPSec (RFC2104) at:
>> http://www.ietf.org/mail-archive/web/tls/current/msg09832.html
>> The same RFC references the Preneel-van-Oorschot paper.
>>
>> I take your question that you actually read RFC2104 and the
>> Preneel-van-Oorschot paper and you disagree with their points?
> 
> Actually, I did, and I don't disagree with their points, but I
> disagree with _your_ points.

I am confused now. My point was to truncate the MAC and this is what
RFC2104 and the paper argues for. What do you actually disagree with?

>> PS. I attach the comment of Bart Preneel on the topic (a cryptographer
>> with significant expertise on hash functions).
> In which he says he was right for the wrong reasons. So, you need to
> reference the right papers (i.e. the ones that describe key recovery
> attacks) so we can evaluate the severity of these attacks. I am not
> aware of any even vaguely practical attacks against even HMAC-MD5, let
> alone any HMAC we're actually contemplating.
> Please present your evidence.

Since you are the one claiming that MAC truncation isn't necessary when
all existing protocols do it (even TLS does it on the Finished message
MAC), it may be better for you to present evidence that this isn't
necessary. Just add a paragraph in the Security considerations of the
existing draft. That would be sufficient for me.

> (Incidentally, he also agrees that the right answer is to have larger
> internal state, not to truncate. SHA-3 gives us this, right?).

I agree, but the discussion was about converting the old ciphersuites
that use HMAC-MD5 and HMAC-SHA1. There is no HMAC-SHA3 (in TLS or
anywhere else).

regards,
Nikos