Re: [TLS] draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD ciphers

David McGrew <> Tue, 27 August 2013 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEC2E11E81FA for <>; Tue, 27 Aug 2013 14:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q9pHbFfRL2R3 for <>; Tue, 27 Aug 2013 14:20:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7B3D911E81D6 for <>; Tue, 27 Aug 2013 14:20:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2405; q=dns/txt; s=iport; t=1377638451; x=1378848051; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=yK3cjvLQN4/f4l0RmPkz5M0h3vJ5tDT0kKjoEeiwNxs=; b=FSziX4pBRRxon1SEkgSQwOvXUmwGtf+sNTJbEby9A9bVqEE/jRIQMu86 9u/nSY57PI88aghQC430Gkbiap2HlloWEDSeREU36ILUryjtCvi1UGg2A /ia3WaUsAdNZLZEaE9Hud+VVA6CwE8OHQis4xm5Szx1TRIitcMIAEXI3N A=;
X-IronPort-AV: E=Sophos;i="4.89,970,1367971200"; d="scan'208";a="252378167"
Received: from ([]) by with ESMTP; 27 Aug 2013 21:20:51 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id r7RLKo3u031236; Tue, 27 Aug 2013 21:20:50 GMT
Message-ID: <1377638449.4027.222.camel@darkstar>
From: David McGrew <>
To: Wan-Teh Chang <>
Date: Tue, 27 Aug 2013 17:20:49 -0400
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4-3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc:, "" <>, Ryan Sleevi <>
Subject: Re: [TLS] draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD ciphers
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Aug 2013 21:20:56 -0000

Hi Wan-Teh,

thanks to you and Ryan for identifying and raising this issue, more

On Wed, 2013-08-21 at 10:49 -0700, Wan-Teh Chang wrote:
> While reviewing the NSS patch for the AES-GCM TLS cipher suites, my
> colleague Ryan Sleevi noticed that the AEAD algorithms defined in
> draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD
> ciphers. The problem is how TLS 1.2 specifies the additional
> authenticated data for AEAD ciphers:
> RFC 5246 Section says:
>    The plaintext is the TLSCompressed.fragment.
>    The additional authenticated data, which we denote as
>    additional_data, is defined as follows:
>       additional_data = seq_num + TLSCompressed.type +
>                         TLSCompressed.version + TLSCompressed.length;
>    where "+" denotes concatenation.
> So additional_data includes the length of the plaintext
> (TLSCompressed.length). But a TLS 1.2 record only gives us the length
> of the AEAD ciphertext. So the recipient needs to calculate the
> plaintext's length using only the ciphertext.
> This is difficult to do with the AEAD algorithms in
> draft-mcgrew-aead-aes-cbc-hmac-sha2 because the amount of padding, and
> therefore the plaintext length, is only known after CBC decryption.

Yes, this is true.

Given the CBC decryption key, it is not hard to find the length of the
plaintext (and the final block can be decrypted as P_n = AES-DEC(K, C_n)
XOR C_{n-1} without decrypting any other blocks, if that is desired).
But it would be undesirable to use this technique, since we want the key
to "stay inside" the AEAD algorithm.  

RFC 5116 asks that each algorithm "provide a description relating the
length of the plaintext to that of the ciphertext."   What you have
found is that draft-mcgrew-aead-aes-cbc-hmac-sha2 provides a
relationship for finding the ciphertext length from the plaintext
length, but not the reverse, and it is impossible to find that reverse
relationship without the secret key.  

All of the AEAD algorithms in the registry (which are based on CCM, GCM,
and SIV) use counter-mode style encryption, and don't have this

I have some thoughts on changes that can improve the situation, which
I'll send in reply to John's email.



> Is this a known problem with TLS 1.2 AEAD ciphers?
> Wan-Teh Chang