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, 28 August 2013 14:59 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 E1F8921F9FE3 for <tls@ietfa.amsl.com>; Wed, 28 Aug 2013 07:59:51 -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 tNn3y-u1id-p for <tls@ietfa.amsl.com>; Wed, 28 Aug 2013 07:59:36 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 342FB21F8C7C for <tls@ietf.org>; Wed, 28 Aug 2013 07:59:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4190; q=dns/txt; s=iport; t=1377701976; x=1378911576; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KugghZiGq58SSviT6fuZ6mXPGtOCV1kJQrKeW5kTZPE=; b=kR+xPV29s8cKDoszfHYjOKhCTS7CVJtBYG/rdT28S/PaRd06JvcKdiln qeGDOvJaxfvZN9v6xWFpAii0FaHdYJw4YGt57/Z8I3mYhHDvd7GN5g2TJ xV/1JT6KVViQkqblTxv2L4g/cv68+XlModXkmyZTwVPB/p7cWZPbm31tp w=;
X-IronPort-AV: E=Sophos;i="4.89,976,1367971200"; d="scan'208";a="252706598"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 28 Aug 2013 14:59:36 +0000
Received: from [64.102.54.158] (dhcp-64-102-54-158.cisco.com [64.102.54.158]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7SExZZf019272; Wed, 28 Aug 2013 14:59:35 GMT
Message-ID: <521E1056.5070309@cisco.com>
Date: Wed, 28 Aug 2013 10:59:34 -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: David McGrew <mcgrew@cisco.com>
References: <CALTJjxEjN04jfCb=mjo1ZWPvgX_sw0Dw6v+AMPKdXp=9BbCxow@mail.gmail.com> <5215102B.30200@cisco.com> <1377638822.4027.228.camel@darkstar>
In-Reply-To: <1377638822.4027.228.camel@darkstar>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 08 Sep 2013 17:44:58 -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, 28 Aug 2013 14:59:53 -0000

Hi David,

CTS is a great idea.  This looks like it could be used to solve the
problem.  We could certainly go this route.  However, thinking through
the implementation details, is CTS widely deployed?  I'm fairly certain
OpenSSL doesn't support CTS.  Is there an RFC that defines AES-CBC-CTS
mode?  If not, would we need to propose an IETF draft for this new
mode?  Thinking through both the standards process and implementation
process, it might looking something like:

1) Author new draft for AES-CBC-CTS mode that coincides with NIST 800-38A?
2) Revise [draft-mcgrew-aead-aes-cbc-hmac-sha2] to include AES-CBC-CTS mode.
3) Register new AES-CBC-CTS TLS cipher suites with IANA.

And moving on to implementation (e.g. OpenSSL, GNUTLS, etc.)...
4) Implement block cipher mode AES-CBC-CTS
5) Add support for the new cipher suites to TLS stack

To second your final comment, what gain would come from this new
AES-CBC-CTS mode for TLS?  Does it achieve anything that GCM mode
doesn't provide today?  It's not clear to me this new mode would be
providing additional value.  Is this merely continued expansion of the
ever increasing list of TLS cipher suites?

John


On 08/27/2013 05:27 PM, David McGrew wrote:
> Hi John,
>
> On Wed, 2013-08-21 at 15:08 -0400, John Foley wrote:
>> 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.
> another alternative would be to define a CBC based ciphersuite that uses
> Cipher Text Stealing [1].   Then the plaintext and ciphertext lengths
> would be off by a constant, as with the other AEAD algorithms.  Now, the
> existing padding method is used by the current draft because that method
> is commonly implemented in CBC libraries (it dates back to early PKCS),
> especially those used in JOSE.   But if it is desirable, we could define
> a CBC algorithm that used CTS.   Since some JOSE adopters have already
> implemented the current version of the draft, they may want to stick
> with the current algorithm.  
>
> David
>
> P.S. - or we could stop using CBC, which is something that deserves
> serious discussion.
>
> [1]
> http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-38A.pdf
>
>>
>>
>>
>> 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
>>> .
>>>
>
> .
>