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

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Wed, 21 August 2013 21:21 UTC

Return-Path: <prvs=194521709e=uri@ll.mit.edu>
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 6AED811E812B for <tls@ietfa.amsl.com>; Wed, 21 Aug 2013 14:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.723
X-Spam-Level:
X-Spam-Status: No, score=-5.723 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
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 wSHPCpybKQu5 for <tls@ietfa.amsl.com>; Wed, 21 Aug 2013 14:21:44 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id C021D21F9E98 for <tls@ietf.org>; Wed, 21 Aug 2013 14:21:44 -0700 (PDT)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r7LLLaAq024045; Wed, 21 Aug 2013 17:21:42 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: "'foleyj@cisco.com'" <foleyj@cisco.com>, "'wtc@google.com'" <wtc@google.com>
Date: Wed, 21 Aug 2013 17:21:41 -0400
Thread-Topic: [TLS] draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD ciphers
Thread-Index: Ac6etArI4JNUxxsSRP+UPjB3aQvYKwAAB1Rl
In-Reply-To: <5215102B.30200@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-21_08:2013-08-21, 2013-08-21, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308210171
Message-Id: <20130821212144.C021D21F9E98@ietfa.amsl.com>
Cc: "'tls@ietf.org'" <tls@ietf.org>, "'sleevi@google.com'" <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 21:21:51 -0000

How many AEAD modes do we care to have?

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <uri@ll.mit.edu>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

 

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>


DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: John Foley [mailto:foleyj@cisco.com]
Sent: Wednesday, August 21, 2013 03:08 PM
To: Wan-Teh Chang <wtc@google.com>
Cc: tls@ietf.org <tls@ietf.org>rg>; 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

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls