Re: [TLS] padding bug

Nikos Mavrogiannopoulos <nmav@gnutls.org> Sun, 08 September 2013 14:25 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 5763221E8082 for <tls@ietfa.amsl.com>; Sun, 8 Sep 2013 07:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 ulTUulk+ShA1 for <tls@ietfa.amsl.com>; Sun, 8 Sep 2013 07:25:20 -0700 (PDT)
Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5361D11E80D5 for <tls@ietf.org>; Sun, 8 Sep 2013 07:25:20 -0700 (PDT)
Received: by mail-ea0-f171.google.com with SMTP id n15so2603348ead.16 for <tls@ietf.org>; Sun, 08 Sep 2013 07:25:15 -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=awj0lqtqAQC3rduINpSzMEtIrxwC6jEDKdoGh8EKKLM=; b=Gr4pesXlY5XrrgOGcTZsRzTJ01u9M84lLbGshFMgWPHu3plT0FUkIpCB+4xbp3AaNo hG1yQ/fBVXpxYmtM9K85KmnoUe3F9sQyqWQVc8aW7J3WdAyZCbMMxbPpHJ6DaXgq+fR3 8Wh4/QbKI/5bJx7UM/gl2wYL+L0u7oSqrI/Fquj+NcQ/kNo0QQQnEeY0kMqvYgg+JDfN MWQyVOn8iCnS8QpZwq0ArWXwoQRUO2wPlX+TKxkmw5LR4BOf+urDg24bC7fA4K5pj59q QodjKC/HYMYLZKIP8n93XE1nEEKZpzcH3DfmJHeW+UFNGABY7+zsYGCsh3LdmLjbBVU2 vsaQ==
X-Received: by 10.14.184.132 with SMTP id s4mr22405917eem.13.1378650315398; Sun, 08 Sep 2013 07:25:15 -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 a43sm13917630eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Sep 2013 07:25:14 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <522C88D8.5030702@gnutls.org>
Date: Sun, 08 Sep 2013 16:25:28 +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: Peter Saint-Andre <stpeter@stpeter.im>
References: <AAE0766F5AF36B46BAB7E0EFB927320630E4A54175@GBTWK10E001.Technology.local> <522BE808.4090405@stpeter.im>
In-Reply-To: <522BE808.4090405@stpeter.im>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
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: Sun, 08 Sep 2013 14:25:22 -0000

On 09/08/2013 04:59 AM, Peter Saint-Andre wrote:

>> As I recall there were three proposals for resolving the padding
>> bug in TLS
> 
>> 1.       An extension for Pad First (i.e. padding before an
>> otherwise standard TLS mode of operation)
> 
>> 2.       An extension for Encrypt-then-MAC (i.e. this draft)
> 
>> 3.       The replacement of each existing cipher suite with an 
>> equivalent AEAD one
> 
>> Was any consensus achieved as to the best approach?
> 
> I never saw further discussion on this topic. Are there I-Ds for each
> approach? #3 seems onerous to me (and doubling the number of cipher
> suites doesn't seem like a desirable outcome), and as far as I can
> tell there's no specification for #1. Although I am not a TLS expert,
> the Encrypt-then-MAC I-D referenced above seems reasonable, it neatly
> solves a real-world problem, and we have running code; thus IMHO
> formalization of this approach deserves to be considered in the WG.

It is important when trying to solve an issue not to introduce new
issues. The current proposal for #2 unfortunately does not take into
account known counter-measures for key recovery attacks in MACs (see [0]).

regards,
Nikos

[0]. http://www.ietf.org/mail-archive/web/tls/current/msg09520.html