Re: [TLS] padding bug

Ben Laurie <benl@google.com> Tue, 24 September 2013 10:24 UTC

Return-Path: <benl@google.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 1D9D621E805F for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 03:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 FwXRsPJZKE4P for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 03:24:19 -0700 (PDT)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4420521E8056 for <tls@ietf.org>; Tue, 24 Sep 2013 03:24:19 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id at1so8866416iec.30 for <tls@ietf.org>; Tue, 24 Sep 2013 03:24:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XJBDM/Cb9nTev8e2yI9ZsXgNt864FvgFF25k7Ax6GWc=; b=Ai5EjoAoK4Ckw8DM3ea1RpiJLZrhulROqg4TOzSRnucNOr3Tj+D2Yf1YoVz3hUuDQz toKIf6yZcXvjMS8SNtq6b1RKDbfxkLtyZ8uHACgPpfj1fO+z1nQNl0Zki1wAQEkZgfJr U8rfOf9V2Q5K2hvwWfreVO1bQmalRj0+GDP4eDHHf2yP2r9/+hn+fN+d2mgK8NoKuq8S UjwuqFXF2ggPnCbG7u4ujt0sAiksVtSOBN1ArredvrL48AZesiY1qv5vHRqNML5ncPWc nshLHkyhuM+WvN1WDXPPKf7DtdeWBNLS2R8Hz57L3Jkzr/6o7htgmRmPdhi9JmD/O+8T utXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XJBDM/Cb9nTev8e2yI9ZsXgNt864FvgFF25k7Ax6GWc=; b=EGq/6gHkFsZ4K1WpeuW8121MkedgCxE9QZr/xWn85PMzH2n3HFE7hKN6O1yx7BMdCg NLih8pPgfC/TXAzSCY461k8AVMxfRKvFeG+bP/ZOesa0TwOiZ6GoQO7Lm0502cpHl9up 99RaWo1XeC7BXP//N31QPLQ+ptzGN6VCk2zJ4a8vXdoJOLnRBNsbkOJ1S2TvrgS/v4c1 DXR7kGdrb0mq6oe4tl9Nkb/Y2YUJZhGDEEsN5nQsWmsl4UBMEL/zugBBAX+MbfIMOsCP jk1SiqpGGpoxsPi4oGxHzdYrXXlJjHY3diCDFmsH23+pqO2uALW/EV26iV6X7E47b9nA 7sVw==
X-Gm-Message-State: ALoCoQmgih+J4zKRGEFFtZ3TWfiSh+dZyGwPPO3FoIgfaxeRwCABp8TKyIiOPB481+bt+VYygJtyAjT796Udk7lhOKNO5ucpAjdOuwJANX4Xr3zH0xmLEF8StcZPO3bDp+ScQAt/JoWHxzaXAmvGG1zmF6qGqmPbYTZPPL8zojOFoPUlGK4QZUpWeoK+8rhuu8IMpCZRZNXq
MIME-Version: 1.0
X-Received: by 10.42.92.84 with SMTP id s20mr8133166icm.63.1380018258674; Tue, 24 Sep 2013 03:24:18 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Tue, 24 Sep 2013 03:24:18 -0700 (PDT)
In-Reply-To: <524148C3.7090709@gnutls.org>
References: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz> <524148C3.7090709@gnutls.org>
Date: Tue, 24 Sep 2013 11:24:18 +0100
Message-ID: <CABrd9SRHheYhNjcbKosaEASfJ6EvZtN93HaLG=Cvzn_1ohKFgw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset=ISO-8859-1
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 10:24:20 -0000

On 24 September 2013 09:09, Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote:
> On 09/24/2013 07:17 AM, Peter Gutmann wrote:
>> Just a small amount of Schadenfreude here when I point out that as I was
>> reading through the long list of GnuTLS security advisories at
>> http://www.gnutls.org/security.html it seems that a number of them would have
>> been avoided through the use of the EtM that Nikos has been so strongly
>> opposed to :-).
>
> I don't understand what does this prove. I was one of the first to ask
> for a solution to the issue. Pointing an issue in your draft doesn't
> mean I'm against solving the problem.

The issue you claim is that it does not defend against key recovery
attacks. I am not aware of any key recovery attacks against HMAC, and
MAC truncation was not proposed as a countermeasure for a key recovery
attack against any MAC.

Can you provide a reference for your claim?