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

John Foley <foleyj@cisco.com> Wed, 21 August 2013 19:08 UTC

Return-Path: <foleyj@cisco.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 2872C11E8133 for <tls@ietfa.amsl.com>; Wed, 21 Aug 2013 12:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 VUo7HR-EDEEv for <tls@ietfa.amsl.com>; Wed, 21 Aug 2013 12:08:28 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 175F711E8122 for <tls@ietf.org>; Wed, 21 Aug 2013 12:08:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1929; q=dns/txt; s=iport; t=1377112108; x=1378321708; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MsBAzQM+MxkDXuTjuKQbUPs9E8b9HIeD24M0JBW5SlQ=; b=m5njj59zyR1lH/ni0qZlyk6pCeNZieJDHT7uUXed3+z9BPtUS+D08PPP /Q1Ce/N25JF25syfIrH1dr6Et3uvRQT1GJG5UChpfu8tIwTI7T9i9tfkO d+HumZ5KK2ABEadJPqX09x6T5g301MjhdSlMkWOFtseBM84ipzgP9ynVF I=;
X-IronPort-AV: E=Sophos;i="4.89,929,1367971200"; d="scan'208";a="250116072"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 21 Aug 2013 19:08:27 +0000
Received: from [64.102.54.158] (dhcp-64-102-54-158.cisco.com [64.102.54.158]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7LJ8Rgx005104; Wed, 21 Aug 2013 19:08:27 GMT
Message-ID: <5215102B.30200@cisco.com>
Date: Wed, 21 Aug 2013 15:08:27 -0400
From: John Foley <foleyj@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wan-Teh Chang <wtc@google.com>
References: <CALTJjxEjN04jfCb=mjo1ZWPvgX_sw0Dw6v+AMPKdXp=9BbCxow@mail.gmail.com>
In-Reply-To: <CALTJjxEjN04jfCb=mjo1ZWPvgX_sw0Dw6v+AMPKdXp=9BbCxow@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 21 Aug 2013 14:18:52 -0700
Cc: "tls@ietf.org" <tls@ietf.org>, Ryan Sleevi <sleevi@google.com>
Subject: Re: [TLS] draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD ciphers
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: Wed, 21 Aug 2013 19:08:34 -0000

Agreed, RFC 5246 section 6.2.3.3 is written for AEAD ciphers that grow
the payload by a fixed length. [draft-mcgrew-aead-aes-cbc-hmac-sha2]
grows the payload by a variable length because CBC mode is used.  The
only way to use this with TLS 1.2 would be to violate the spec by
increasing the TLSCompressed.length by the pad value prior to
encrypting.  Then when decrypting we would have the appropriate value
for the additional data input.

It seems that [draft-mcgrew-aead-aes-cbc-hmac-sha2] needs to include a
section to revise RFC 5246, or another draft is required that revises
5246 to allow use of variable pad length AEAD ciphers.




On 08/21/2013 01:49 PM, 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 6.2.3.3 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.
>
> Is this a known problem with TLS 1.2 AEAD ciphers?
>
> Wan-Teh Chang
> .
>