Re: [TLS] On the possibility of AEAD modes that require padding
Yoav Nir <ynir.ietf@gmail.com> Fri, 20 June 2014 20:25 UTC
Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4B01B290F for <tls@ietfa.amsl.com>; Fri, 20 Jun 2014 13:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTDt7hSjiiPn for <tls@ietfa.amsl.com>; Fri, 20 Jun 2014 13:25:31 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282A31B290D for <tls@ietf.org>; Fri, 20 Jun 2014 13:25:29 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id cc10so1378784wib.12 for <tls@ietf.org>; Fri, 20 Jun 2014 13:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wKrAnoUNG3kVSAqC/JDzh/YUu0kMQ4WYllxF0mDoAW4=; b=N6Lf0S2X/AKfz6ESdjvzuMS6/xon3VR7X2F+u4hjfjYP8gkZKKniMv0MSIO7ryPZkW 3wwkIMnFuJFyBt6O/rTXxbIIFgWWrDXHC+tMBESEyX7jAZb08fLdSE2G9NGqekufqICr gMxf8GsENXlKXwGsSRiNpqUxFNjCQptyJbovGR9qWJU0dlWI3PYact9tZz8v2cQT31bp mFJWXYoUCkT9VnFFvCIwwTKMSftBKbsGBpUA95o0MTir8OghLmf76kZv7QbU0Yjel0if fVuypuXlclLPRfqmZDuMlgvmzlwW/E4W7r6RsJFiv2Zb99XDJ3ggVwkai6HwzI/hH0GG fNYw==
X-Received: by 10.180.99.99 with SMTP id ep3mr6742624wib.42.1403295927723; Fri, 20 Jun 2014 13:25:27 -0700 (PDT)
Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id am10sm17701599wjc.45.2014.06.20.13.25.26 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 13:25:27 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <87k38bzc0h.fsf@alice.fifthhorseman.net>
Date: Fri, 20 Jun 2014 23:25:27 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <3422AC27-DC99-49AC-87EC-EFFC9F883D98@gmail.com>
References: <87k38bzc0h.fsf@alice.fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hGZkiCsYOBBNKUgRW9SIuY5IM4M
Cc: IETF TLS Working Group <tls@ietf.org>
Subject: Re: [TLS] On the possibility of AEAD modes that require padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 20 Jun 2014 20:25:33 -0000
On Jun 20, 2014, at 9:11 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > hi IETF folks-- > > If an AEAD mode is ever defined that must pad its input to a blocksize > before encrypting, the current spec seems like it will break. > > This is a currently-theoretical concern, since (fixed authentication tag > notwithstanding) GCM does not pad its input, and OCB and > chacha20-poly1305 (and other AEAD modes i could find data on) also don't > pad their input. While this hasn’t been proposed directly to the TLS working group there is the CBC-HMAC AEAD in draft-mcgrew-aead-aes-cbc-hmac-sha2. That’s CBC so there is padding as described in section 2.1. Yoav
- [TLS] On the possibility of AEAD modes that requi… Daniel Kahn Gillmor
- Re: [TLS] On the possibility of AEAD modes that r… Adam Langley
- Re: [TLS] On the possibility of AEAD modes that r… Watson Ladd
- Re: [TLS] On the possibility of AEAD modes that r… Eric Rescorla
- Re: [TLS] On the possibility of AEAD modes that r… Daniel Kahn Gillmor
- Re: [TLS] On the possibility of AEAD modes that r… Yoav Nir