Re: [TLS] Resolution AEAD Cipher length and padding

"Joseph Salowey (jsalowey)" <> Mon, 21 July 2014 18:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9AAE91A0235 for <>; Mon, 21 Jul 2014 11:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bRZB0bLgBXYt for <>; Mon, 21 Jul 2014 11:02:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 670371A0023 for <>; Mon, 21 Jul 2014 11:02:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4794; q=dns/txt; s=iport; t=1405965778; x=1407175378; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=voTuaXNWMn2Ur/MkPR5H+pbusXi03W8qCYI1RphjODo=; b=L5ApCaMDuhgRxkLjmIyOTIoBs6NkZuhA43AG4W8j61gQQa2516Awv3lY jdys8nhqASh5ilf/3OSKQ3qFpj31CJrtxzKYoen3a2iZHy8VksUESlqpB 2lXwXk8E2bBxG5qNV/p3CJ3nVP/GpUyCFYizWYun7wiEc3cjWn3I6NdDK s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.01,702,1400025600"; d="scan'208,217";a="341685681"
Received: from ([]) by with ESMTP; 21 Jul 2014 18:02:57 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s6LI2vLI005085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 18:02:57 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 13:02:57 -0500
From: "Joseph Salowey (jsalowey)" <>
To: Bodo Moeller <>
Thread-Topic: [TLS] Resolution AEAD Cipher length and padding
Date: Mon, 21 Jul 2014 18:02:57 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F622B101CC844AF19D9591E1ABE8158Cciscocom_"
MIME-Version: 1.0
Cc: "<>" <>, Alfredo Pironti <>
Subject: Re: [TLS] Resolution AEAD Cipher length and padding
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Jul 2014 18:03:01 -0000

On Jul 21, 2014, at 8:33 AM, Bodo Moeller <<>> wrote:

Joseph Salowey (jsalowey) <<>>:
On Jul 21, 2014, at 7:54 AM, Alfredo Pironti <<>> wrote:

It's not clear to me what this resolution is about; could you please elaborate (or give pointers)?
Is this about AEAD ciphers built on top of block-encrypt then mac? To some extent, current GCM and CCM ciphers are already expanding the cipher text length by the tag length, so I must be missing the point here. Thanks.

[Joe] to clarify:  current AEAD cipher modes (GCM, CCM)  do not expand the cipher text through padding, their cipher text length is the same as the clear text length.

I think the authentication tag (8 octets for these -- RFC 5288 or RFC 6655) is considered part of the ciphertext for the AEAD interface (RFC 5116) as used by TLS 1.2 (RFC 5246), so length expansion indeed already takes place.  So unless I'm missing something, the point actually is that with these the exact amount of length expansion is implicit (and you can recover TLSPlaintext.length and thus determine additional_data by subtracting a constant from the ciphertext length).

Thus, this decision is not about padding per se, but specifically about *variable* padding, which wouldn't work with the current spec.

[Joe] Yes, that would be more accurate - variable length padding added as part of the encryption process.