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

David McGrew <mcgrew@cisco.com> Tue, 27 August 2013 21:27 UTC

Return-Path: <mcgrew@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 A520C11E8303 for <tls@ietfa.amsl.com>; Tue, 27 Aug 2013 14:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSWnjW90tafV for <tls@ietfa.amsl.com>; Tue, 27 Aug 2013 14:27:05 -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 DCA3D11E8258 for <tls@ietf.org>; Tue, 27 Aug 2013 14:27:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2903; q=dns/txt; s=iport; t=1377638824; x=1378848424; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=lxIHWKcobT1IQGl1+mDpTbANrUBBm1sA43lAoZyRnGQ=; b=iPVsXDpZOvdc+W+HkUlNrvUwQW/1kfVKshkDwhEaKCKyzk9IaXoktOZe pSny1Srk0Hl6OeYnhQLKeQpyfewG4y8limZHxyMYIm/hobqT2Va020J3r o2EE4opQ2qqUgyHiatiTyKAYqrL/FdpyEz8JysTZv67+U2TgMAnioIhIQ M=;
X-IronPort-AV: E=Sophos;i="4.89,970,1367971200"; d="scan'208";a="252380123"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 27 Aug 2013 21:27:03 +0000
Received: from [10.0.2.15] (rtp-mcgrew-8912.cisco.com [10.117.10.227]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7RLR2E2028020; Tue, 27 Aug 2013 21:27:03 GMT
Message-ID: <1377638822.4027.228.camel@darkstar>
From: David McGrew <mcgrew@cisco.com>
To: John Foley <foleyj@cisco.com>
Date: Tue, 27 Aug 2013 17:27:02 -0400
In-Reply-To: <5215102B.30200@cisco.com>
References: <CALTJjxEjN04jfCb=mjo1ZWPvgX_sw0Dw6v+AMPKdXp=9BbCxow@mail.gmail.com> <5215102B.30200@cisco.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4-3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
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: Tue, 27 Aug 2013 21:27:09 -0000

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
> > .
> >
>